TUN inbound: Enhance Darwin interface support

[Owersun]

• reduce number of actions done to create/configure the interface in the system,
• assign synthetic static link-local ip address to the interface, that is required by the OS to just be available for routing,
• make tun_darwin_endpoint be implemented significantly more similar to tun_windows_enpoint, preparing them for potential unification,
• added MacOSX specific README.md section,

I checked the functionality on my local machine to work, checking every element make sense, and functions call proper ioctl's.

[RPRX]

#5559 (comment) 提到简单改一下就能在 iOS 上跑，可以并入这个 PR

@evozi-team 测试一下这个 PR 对于 iOS 有改进吗

[Owersun]

I was planning to check how this can be extended for iOS support as a next step.
Was planning to have it as further enhancement PR later. This is just "de-vibing" the initial Darwin support, and making it as close as possible to how windows/linux is working.

[RPRX]

那这个 PR 不急着合并，还有五天的时间，有新的 changes 直接放这里就行

[RPRX]

可以先 rebase 445c0d4 ，方便 @evozi-team 测下 iOS

[RPRX]

现在的 TUN 还剩个 macOS 上的进程名路由 #5559 (comment) 和三个平台上的 auto-toute #5594 (comment) 就差不多了

v2rayN 那边可能都是直接用那两家的 auto-route 而不是自己操作路由表的

[Owersun]

I've investigated the iOS support.
An iOS application build with a golang part, is a process when native XCode iOS app is created and then bind to some golang app (https://go.dev/wiki/Mobile#building-and-deploying-to-ios-1)
Meaning the main application in this case is some XCode project create app, and golang is "included" in it as some kind of external library.
Using tunnel interface in this case require main XCode app to create a tunnel through native iOS methods, and then pass it to the golang app through bind function as a memory structure with some methods. Then golang app can start the loop lifecycle around that passed structure reading and writing into it.

This all sounds to me, like to have real iOS support I need to see at least one real life implementation of an iOS app that uses XRay-Core as that kind of "bind" application/library.
And then I can design tun_ios.go around what that application is going to have.
I already has "sample" implementation around very generic ios NEPacketTunnelProvider structure, but it has no "native" ios main app it should be included in, so I can't even test it or say that it works in any proper way.
It would be nice, if people who requested iOS support would point me to their repository where the "main" app that plans to use XRay-Core that way is. Then I can tie them together and test.

Besides that the darwin/macos enhancement, which also includes unification with windows enpoint (because they really work similar), is done in this pull request.
If I'd have a link to iOS app that uses XRay-Core as golang library, I can evaluate how good iOS support can be, if not - this PR can be merged as is, and I can do iOS later.

[RPRX]

Rebase 一下吧，ready 了就合并

[Owersun]

Rebased on top of main.
There are two commits in this branch, I'd like to keep them separate, as they do different things. One is darwin enhancements, the other is unification of windows/darwin endpoint. They are independent.

[RPRX]

看起来还是没有 rebase

[Owersun]

Something went wrong with all the force updates and syncs between main and Owersun/main. I refreshed everything and pushed everything clean anew. Now there is exactly two commits on top of current main

[dereference23]

@Owersun is it possible to have split tunneling with this on macOS? I'm not a network guy but I tried to do my best. This is what I did (en1 here is my Wi-Fi interface):

1. sudo route add -host <VLESS IP>/32 <en1's gateway IP>
2. sudo route delete default
3. sudo route add default -interface utun20

In my xray config, I have added "sockopt": { "interface": "en1" } to the outbounds. It works perfectly with VLESS routes but doesn't work with "protocol": "freedom" routes. I also tried sendThrough instead of sockopt.interface, the result was the same. And I guess in theory it shouldn't be needed to do step 1 when specifying interface but it doesn't work like that too. Maybe there is something I'm missing here