He estado indagando en el código fuente de Darwin para intentar encontrar alguna forma de crear interfaces Ethernet virtuales en Mac/Darwin sin añadir una extensión del kernel como tuntaposx. Al hacerlo he encontrado algo interesante que parece existir pero que tiene cero documentación.
Aquí está el archivo fuente:
https://opensource.apple.com/source/xnu/xnu-4570.41.2/bsd/net/if_fake.c.auto.html
La lectura del archivo me lleva a pensar que esto es similar a un par veth en Linux: crea dos interfaces y los paquetes que entran en una salen por la otra.
El único problema es que puedo encontrar nada en Internet sobre esto.
He podido confirmar que existe a partir de OSX Mojave y supongo que también existen en versiones anteriores:
# ifconfig feth0 create
feth0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 66:65:74:68:00:00
peer: <none>
media: autoselect
status: inactive
Después de buscar un poco más parece que he encontrado una opción no documentada en ifconfig para enlazar dos de estos:
# ifconfig feth0 peer feth1
# ifconfig feth0
feth0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 66:65:74:68:00:00
inet 9.9.9.9 netmask 0xffffff00 broadcast 9.9.9.255
peer: feth1
media: autoselect
status: active
Ahora cuando añado una IP a feth0 y tcpdump feth1, veo un montón de paquetes que son cosas como anuncios de mDNS que uno esperaría que un Mac arrojara en un nuevo enlace Ethernet.
Lo pongo aquí porque tengo curiosidad por saber si alguien más tiene idea de esto o lo ha usado alguna vez.
Edito: Ahora puedo confirmar que si los emparejas y subes ambos (ifconfig feth0 up, etc.) puedes inyectar paquetes en cualquiera de los dos lados y verlos en el otro. Parece que esto podría funcionar como un dispositivo de toma de Ethernet de capa 2 o un dispositivo de par veth de máquina virtual sin requerir una extensión del kernel. Esto no sólo es impresionante para la virtualización de la red, sino que junto con las extensiones de virtualización de Apple también permitiría un host de máquina virtual sin kext con capacidades de red completas.
Edición #2: También acabamos de encontrar esto, que tampoco está muy bien documentado aunque es mucho mejor que feth. Es posible que ofrezca una forma más oficial de crear dispositivos Ethernet virtuales. Tendremos que ver cómo funciona. Sin embargo, lo de feth sigue siendo interesante.