macos ifconfig 多了 feth 2 接口，多了 ip

feth8846: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 2800
ether 66:65:74:68:22:8e
peer: feth3846
media: autoselect
status: active
feth3846: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 5000 mtu 2800
ether b6:a3:48:18:44:6b
inet 10.147.20.93 netmask 0xffffff00 broadcast 10.147.20.255
peer: feth8846
media: autoselect
status: active

导致spring 项目，向注册中心注册时，读取到这个 ip.
后来在 linux.do 论坛 问才知道，时 zerotier 点对点的 网络接口.

feth = fake Ethernet

https://www.zerotier.com/blog/how-zerotier-eliminated-kernel-extensions-on-macos/

推荐个 macos 卸载工具， 开源免费。 Pearcleaner

---

How ZeroTier Eliminated Kernel Extensions on MacOS
Zerotier如何消除MacOS上的内核扩展
… version 10.13 or newer at least …
…版本10.13或至少更新…

Since we first released ZeroTier for MacOS we’ve used a kernel extension based on a stripped down and rebranded version of tuntaposx. In our version we increased the maximum MTU, removed tun support (we only use tap), and changed the interface names to start with “zt”.
自从我们首次发布了MacOS的Zerotier以来，我们已经根据TuntapoSX的脱衣舞和更名的版本使用了内核扩展。在我们的版本中，我们增加了最大MTU，删除了TUN支持（我们只使用TAP），然后更改了接口名称以“ ZT”开头。

To release this kernel extension we had to get a special kernel extension signing key from Apple, which was about as easy as getting security clearance to see alien bodies at Area 51. We built it, signed it, and haven’t rebuilt it for years.
要发布此内核扩展，我们必须从Apple那里获得一个特殊的内核扩展签名密钥，这与获得安全许可在51区看到外星人的身体一样容易。我们建造了它，签名并没有重建多年。

We learned a while ago that Apple wants to phase out conventional kernel extensions for obvious reasons: they’re a massive security and stability “hole”. This process is likely going to start with the upcoming MacOS Catalina release.
不久前，我们了解到，苹果希望出于明显的原因逐步淘汰传统的内核扩展：它们是一个巨大的安全性和稳定性的“漏洞”。这个过程可能会从即将发布的MacOS Catalina版本开始。

Back when the first ZeroTier release for Mac was being developed a search was performed to determine if a way existed to avoid the kernel extension requirement. Back then we came up empty-handed. When we learned of Apple’s impending plans to sunset kernel extensions we repeated our search and this time we delved deep, going so far as to actually read the Darwin kernel’s source code at opensource.apple.com.
回到开发Mac的第一个Zerotier版本时，进行了搜索，以确定是否存在一种方法来避免内核扩展要求。那时我们空手而出。当我们得知苹果迫在眉睫的日落内核扩展计划的计划时，我们重复了搜索，这次我们深入研究了，甚至可以在o ​​pensource.apple.com上实际阅读darwin内核的源代码。

We found something! It appeared silently in MacOS 10.13, seemed to do what we needed, but had absolutely no documentation whatsoever.
我们找到了一些东西！它在MacOS 10.13中默默显示，似乎做了我们需要的事情，但绝对没有任何文件。

Starting in 10.13 Darwin contains something called a “fake Ethernet” device. They start with “feth”, can be created with the “ifconfig” command, and appear to behave very much like “veth pairs” on Linux. Create two “feth” interfaces, peer them, and now packets injected in one come out of the other.
从10.13开始，达尔文包含一个称为“假以太网”设备的东西。它们以“ Feth”开头，可以从“ IfConfig”命令中创建，并且似乎非常类似于Linux上的“ Veth Pairs” 。创建两个“ Feth”接口，凝视它们，现在将一个注入一个的数据包出来。

Our Apple Stack Overflow question and now the ZeroTier source code itself remain just about the only result you find when you search on this topic. Since there was no documentation we started experimenting and developed a technique for using these interfaces that seems to work very well and perform decently enough for ordinary desktop use. Performance seems *slightly *worse than the old tap interface kext but not enough to be particularly noticeable.
我们的Apple堆栈溢出问题，现在Zerotier源代码本身仍然是您在搜索此主题时发现的唯一结果。由于没有文档，我们开始尝试并开发了一种使用这些界面的技术，这些接口似乎可以很好地工作，并且可以很好地供普通台式机使用。性能似乎比旧的TAP接口Kext稍差，但不足以特别明显。

The method we found is pure black magic. A BPF (Berkeley Packet Filter) socket seems to be needed to receive packets from the pair, while an AF_NDRV socket (yet another bit of almost undocumented internal magic) seems to be the best way to inject them. Injection can also be done via BPF but the AF_NDRV method seemed to yield superior performance.
我们发现的方法是纯黑魔法。似乎需要一个BPF（Berkeley数据包过滤器）套接字来接收这对数据包，而AF_NDRV套接字（又是几乎无证件的内部魔术的另一一点）似乎是注入它们的最佳方法。还可以通过BPF进行注射，但AF_NDRV方法似乎产生了卓越的性能。

If you’re a coder and want the dirty details check out MacEthernetTapAgent.c.
如果您是编码器，并且想要肮脏的详细信息查看MacEthernettapagent.c 。

If you are using ZeroTier 1.4.2+ and are running MacOS 10.13 or newer, try typing “ifconfig” at the command line. You should see a series of “feth” pairs. Our code computes 4-digit numeric IDs based on network IDs (so they’re always the same) and uses IDs below 5000 for the member of the pair that gets IPs assigned and a corresponding ID above 5000 for the member of the pair used for I/O. (Like Linux “veth” devices they must exist in pairs. A single “feth” device doesn’t appear to want to communicate even if injection and packet sampling is local.)
如果您使用的是Zerotier 1.4.2+并运行MACOS 10.13或更新，请尝试在命令行中键入“ IfConfig”。您应该看到一系列“ Feth”对。我们的代码基于网络ID计算4位数字ID（因此它们始终相同），并为分配IPS的成员使用5000以下的ID，并为对iPS分配的相应ID和相应的ID在5000以上的ID中用于该对的成员I/O。 （就像Linux“ VETH”设备必须成对存在的设备一样。即使注入和数据包采样是本地的，单个“ Feth”设备似乎也不想通信。）

We don’t think the “feth” technique will live forever. Starting in MacOS Catalina Apple is introducing DriverKit. DriverKit replaces old installed-as-root kernel extensions with a more microkernel-like way to run drivers in user-space (somehow, we’re not clear on the details yet).
我们认为“ Feth”技术不会永远存在。从Macos Catalina Apple开始介绍驱动程序。 DriverKit用更类似于微粒的方式来代替旧安装的As-As-As-As-As-As-As-and-bernel扩展程序，以在用户空间中运行驱动程序（以某种方式，我们尚不清楚详细信息）。

It looks very much like DriverKit will let us develop a new Ethernet tap device driver for ZeroTier that runs in user space and works at least as well if not better than the old tuntaposx driver. Once Catalina is out and this API is out of beta we intend to explore this option as this is going to be the “right way” to do it. It should deliver superior performance too. We might even be able to finally put ZeroTier in the Mac App Store for easier installation and updates on MacOS!
看起来很像DriverKit可以让我们为Zerotier开发一个新的以太网TAP设备驱动程序，该驱动器在用户空间中运行，并且至少也比旧的TuntapoSX驱动程序更好。一旦Catalina脱颖而出，此API不超过Beta，我们打算探索此选项，因为这将是这样做的“正确方法”。它也应该提供卓越的性能。我们甚至可以最终将Zerotier放入Mac App Store中，以便于安装和更新MacOS！

Of course we’ll have to keep “feth” around in the code base until versions prior to 10.15 (Catalina) die off, and keep the kernel extension around until versions prior to 10.13 die off. Such is life if you’re trying to support a substantial user base.
当然，我们必须将“ Feth”保持在代码库中，直到10.15（Catalina）之前的版本死亡，并将内核扩展保持在围绕10.13之前的版本中。如果您试图支持大量的用户群，那就是生活。

Edit: 编辑：
People might ask why we don’t use the NetworkExtension framework or the “utun” device type. It’s because NetworkExtension and “utun” only support layer 3 “tun” type interfaces, not layer 2 “tap” interfaces.
人们可能会问为什么我们不使用NetWorkextension框架或“ UTUN”设备类型。这是因为NetWorkextension和“ UTUN”仅支持第3层“ TUN”类型接口，而不是第2层“ TAP”接口。

We do have code to glue a layer 3 tunnel to a layer 2 virtual network by implementing our own IPv4 ARP and IPv6 NDP. This is how we work on phones (iOS and Android). It’s not ideal though. Many desktop users want real “tap” devices for various reasons including bridging to VMs, doing real multicast, and running exotic protocols.
我们确实有代码通过实现我们自己的IPv4 ARP和IPv6 NDP来将第3层隧道粘合到第2层虚拟网络。这就是我们在手机（iOS和Android）上工作的方式。虽然不是理想的。许多桌面用户出于各种原因需要真正的“ Tap”设备，包括桥接到VM，进行真实的多播和运行异国情调的协议。

Apple also seems to have hard-coded an exclusion for “utun” devices into Bonjour and other system services. The fact that these work over ZeroTier is a major draw for MacOS users, so that means we can’t use “utun” or NetworkExtension on desktop (unless Apple broadens these interfaces) without losing quite a lot of capability.
苹果似乎还将“ UTUN”设备排除在Bonjour和其他系统服务中。这些在Zerotier上的工作是Macos用户的主要吸引力，因此这意味着我们不能在桌面上使用“ Utun”或NetWorkextension（除非Apple扩大了这些接口）而不会失去很多能力。