dndx/phantunTransforma flujos UDP en flujos TCP (falsos) que pueden atravesar firewalls/NATs de Layer 3 & Layer 4 (NAPT).
Un ofuscador ligero y rápido de UDP a TCP.
Rust solo proporciona soporte de Nivel 3 para plataformas basadas en MIPS desde 2023. Por lo tanto, las compilaciones de Phantun para MIPS se construyen usando la cadena de herramientas nightly de Rust y se proporcionan solo con el mejor esfuerzo posible.
Phantun es un proyecto que ofusca paquetes UDP en conexiones TCP. Su objetivo es lograr el máximo rendimiento con un procesamiento y una sobrecarga de encapsulación mínimos.
Se usa comúnmente en entornos donde UDP está bloqueado o limitado pero TCP está permitido.
Phantun simplemente convierte un flujo de paquetes UDP en paquetes de flujo TCP ofuscados. La pila TCP utilizada por Phantun está diseñada para atravesar la mayoría de los dispositivos de firewall/NAT con y sin estado de capa 3/4. No podrá atravesar proxies de capa 7. Sin embargo, la ventaja de este enfoque es que no se producirán los problemas comunes de rendimiento de UDP sobre TCP, como las retransmisiones y el control de flujo. Las propiedades subyacentes de UDP, como la entrega fuera de orden, se conservan por completo incluso si la conexión termina viéndose como una conexión TCP desde la perspectiva de los firewalls/dispositivos NAT.
Phantun significa Phantom TUN, ya que es un ofuscador para tráfico UDP que realiza el trabajo suficiente para que este atraviese firewalls/NAT con estado como paquetes TCP.
Phantun está escrito en Rust 100% seguro. Se ha optimizado exhaustivamente para escalar bien en sistemas multinúcleo y no tiene problemas para saturar todos los recursos de CPU disponibles en una conexión rápida. Consulte la sección Rendimiento para ver los resultados de las pruebas comparativas.
En el siguiente ejemplo, se asume que el Servidor Phantun escucha las conexiones entrantes del Cliente Phantun en el
puerto 4567 (la opción --local para el servidor), y reenvía los paquetes UDP al servidor UDP en 127.0.0.1:1234
(la opción --remote para el servidor).
También se asume que el Cliente Phantun escucha los paquetes UDP entrantes en
127.0.0.1:1234 (la opción --local para el cliente) y se conecta al Servidor Phantun en 10.0.0.1:4567
(la opción --remote para el cliente).
Phantun crea una interfaz TUN tanto para el Cliente como para el Servidor. Para el Cliente, Phantun se asigna a sí mismo la dirección IP
192.168.200.2 y fcc8::2 por defecto.
Para el Servidor, asigna 192.168.201.2 y fcc9::2 por defecto. Por lo tanto, su kernel debe tener
el reenvío de IPv4/IPv6 habilitado y configurar las reglas apropiadas de iptables/nftables para NAT entre la dirección
de su NIC física y la dirección de la interfaz Tun de Phantun.
Puede personalizar el nombre de la interfaz Tun creada por Phantun y las direcciones asignadas. Ejecute
el ejecutable con la opción -h para ver cómo cambiarlos.
Otra forma de ayudar a entender esta topología de red (consulte el diagrama anterior para ver una ilustración de esta topología):
El Cliente Phantun es como una máquina con una dirección IP privada (192.168.200.2/fcc8::2) detrás de un enrutador.
Para que pueda llegar a Internet, necesitará aplicar SNAT a la dirección IP privada antes de que su tráfico
salga de la NIC.
El Servidor Phantun es como un servidor con una dirección IP privada (192.168.201.2/fcc9::2) detrás de un enrutador.
Para acceder a él desde Internet, necesita aplicar DNAT a su puerto de escucha en el enrutador
y cambiar la dirección IP de destino a donde el servidor está escuchando conexiones entrantes.
En esos casos, la máquina/iptables que ejecuta Phantun actúa como el "enrutador" que permite que Phantun se comunique con el exterior usando sus direcciones IP privadas.
A partir de Phantun v0.4.1, IPv6 es totalmente compatible tanto para el lado TCP como para el UDP.
Para especificar una dirección IPv6, use el siguiente formato: [::1]:1234 con
las opciones de línea de comandos. También se admite la resolución de registros AAAA. Ejecute el programa
con -h para ver las opciones detalladas sobre cómo controlar el comportamiento de IPv6.
Edite /etc/sysctl.conf, agregue net.ipv4.ip_forward=1 y ejecute sudo sysctl -p /etc/sysctl.conf.
También será necesario establecer net.ipv6.conf.all.forwarding=1.
El Cliente simplemente necesita tener SNAT habilitado en la interfaz física para traducir la dirección de Phantun a una que pueda usarse en la red física. Esto se puede hacer simplemente con masquerade.
Nota: cambie eth0 por el nombre real de la interfaz física
table inet nat {
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
iifname tun0 oif eth0 masquerade
}
}
Nota: La regla anterior usa inet como tipo de familia de tabla, por lo que es compatible tanto con
IPv4 como con IPv6.
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
El Servidor necesita aplicar DNAT al puerto de escucha TCP hacia la dirección de la interfaz TUN de Phantun.
Nota: cambie eth0 por el nombre real de la interfaz física y 4567 por
el número de puerto TCP real utilizado por el servidor Phantun
table inet nat {
chain prerouting {
type nat hook prerouting priority dstnat; policy accept;
iif eth0 tcp dport 4567 dnat ip to 192.168.201.2
iif eth0 tcp dport 4567 dnat ip6 to fcc9::2
}
}
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 4567 -j DNAT --to-destination 192.168.201.2
ip6tables -t nat -A PREROUTING -p tcp -i eth0 --dport 4567 -j DNAT --to-destination fcc9::2
No es recomendable ejecutar aplicaciones orientadas a la red como usuario root. Phantun se puede ejecutar completamente
como usuario no root con la capacidad cap_net_admin.
sudo setcap cap_net_admin=+pe phantun_server
sudo setcap cap_net_admin=+pe phantun_client
Nota: Ejecute el ejecutable de Phantun con la opción -h para ver todas las opciones detalladas.
Nota: 4567 es el puerto TCP en el que Phantun debe escuchar y debe corresponder a la regla DNAT
especificada anteriormente. 127.0.0.1:1234 es el Servidor UDP al que conectarse para nuevas conexiones.
RUST_LOG=info /usr/local/bin/phantun_server --local 4567 --remote 127.0.0.1:1234
O use un nombre de host con --remote:
RUST_LOG=info /usr/local/bin/phantun_server --local 4567 --remote example.com:1234
Nota: El servidor asigna por defecto direcciones privadas IPv4 e IPv6 a la interfaz Tun. Si no desea usar IPv6, simplemente puede omitir la creación de la regla DNAT IPv6 anterior y la presencia de la dirección IPv6 en la interfaz Tun no debería tener efectos secundarios en el servidor.
Nota: 127.0.0.1:1234 es la dirección y el puerto UDP en los que Phantun debe escuchar. 10.0.0.1:4567 es
el Servidor Phantun al que conectarse.
RUST_LOG=info /usr/local/bin/phantun_client --local 127.0.0.1:1234 --remote 10.0.0.1:4567
O use un nombre de host con --remote:
RUST_LOG=info /usr/local/bin/phantun_client --local 127.0.0.1:1234 --remote example.com:4567
RUST_LOG=info /usr/local/bin/phantun_client --local 127.0.0.1:1234 --remote [fdxx::1234]:4567
También se admiten nombres de dominio con registro AAAA.
Phantun busca mantener la sobrecarga de tunelización al mínimo. La sobrecarga en comparación con un paquete UDP simple es la siguiente (usando IPv4 como ejemplo a continuación):
Paquete UDP estándar: 20 bytes de cabecera IP + 8 bytes de cabecera UDP = 28 bytes
Paquete ofuscado: 20 bytes de cabecera IP + 20 bytes de cabecera TCP = 40 bytes
¡Tenga en cuenta que Phantun no agrega ninguna cabecera adicional además de las cabeceras IP y TCP para poder pasar la inspección de paquetes con estado!
Sobrecarga adicional de Phantun: 12 bytes. En otras palabras, al usar Phantun, la carga útil utilizable para
el paquete UDP se reduce en 12 bytes. Esta es la sobrecarga mínima posible al realizar este tipo
de ofuscación.
Para las personas que usan Phantun para tunelizar paquetes UDP de WireGuard®, aquí hay algunas pautas para determinar el MTU correcto para usar en su interfaz WireGuard.
MTU de WireGuard = MTU del enlace - Cabecera IPv4 (20 bytes) - Cabecera TCP (20 bytes) - Sobrecarga de WireGuard (32 bytes)
o
MTU de WireGuard = MTU del enlace - Cabecera IPv6 (40 bytes) - Cabecera TCP (20 bytes) - Sobrecarga de WireGuard (32 bytes)
Por ejemplo, para un enlace de red con un MTU de 1500 bytes, el MTU de la interfaz WireGuard debe establecerse como:
IPv4: 1500 (MTU del enlace) - 20 - 20 - 32 = 1428 bytes
IPv6: 1500 (MTU del enlace) - 40 - 20 - 32 = 1408 bytes
El paquete de datos TCP de Phantun resultante será de 1500 bytes, que no supera el MTU de la interfaz de 1500.
Tenga en cuenta que Phantun no puede funcionar correctamente si
el tamaño del paquete excede el MTU del enlace, ya que Phantun no realiza ninguna fragmentación IP
ni reensamblaje. Por la misma razón, Phantun siempre establece el bit DF (Don't Fragment)
en la cabecera IP para evitar que los dispositivos intermedios realicen cualquier fragmentación en el paquete.
También se recomienda encarecidamente usar el mismo MTU de interfaz en ambos extremos de un túnel WireGuard, de lo contrario, pueden ocurrir pérdidas de paquetes inesperadas y estos problemas son generalmente muy difíciles de diagnosticar.
Si bien la pila TCP es bastante estable, la expectativa general es que debe ejecutar las mismas versiones secundarias del Servidor/Cliente de Phantun en ambos extremos para garantizar la máxima compatibilidad.
Para los usuarios que deseen usar la librería fake-tcp dentro de su propio proyecto, consulte la documentación de la librería en:
https://docs.rs/fake-tcp.
El rendimiento se probó en 2 instancias AWS t4g.xlarge con 4 vCPU y 5 Gb/s de NIC en una LAN. Se usó nftables para redirigir
el flujo UDP de iperf3 a través del túnel Phantun/udp2raw entre las dos instancias de prueba y el MTU se ajustó para evitar la fragmentación.
Se utilizaron Phantun v0.3.2 y udp2raw_arm_asm_aes 20200818.0. Estas eran las versiones más recientes de ambos proyectos en abril de 2022.
Comando de prueba: iperf3 -c <IP> -p <PORT> -R -u -l 1400 -b 1000m -t 30 -P 5
Artículo sobre algunas de las técnicas utilizadas en Phantun para lograr este resultado de rendimiento: Writing Highly Efficient UDP Server in Rust.
udp2raw es otro proyecto popular de @wangyu- que es muy similar a lo que Phantun puede hacer. De hecho, tomé inspiración para Phantun de udp2raw. La razón principal para desarrollar Phantun es la falta de rendimiento al ejecutar udp2raw (especialmente en sistemas multinúcleo como Raspberry Pi). Sin embargo, el objetivo nunca es ser tan completo en funcionalidades como udp2raw y solo admitir los casos de uso más comunes. En particular, no se admiten los modos UDP sobre ICMP ni UDP sobre UDP, y no hay soporte antirreproducción ni cifrado. El beneficio de esto es un rendimiento mucho mejor en general y menos sobrecarga de MTU debido a la falta de cabeceras adicionales dentro de la carga útil TCP.
Aquí hay una visión general rápida de la comparación entre ambos para ayudarle a elegir:
Copyright 2021-2025 Datong Sun ([email protected])
Licenciado bajo la Licencia Apache, Versión 2.0 <LICENSE-APACHE o https://www.apache.org/licenses/LICENSE-2.0> o la licencia MIT <LICENSE-MIT o https://opensource.org/licenses/MIT>, según su elección. Los archivos del proyecto no pueden ser copiados, modificados o distribuidos excepto de acuerdo con esos términos.
| Modo | Velocidad de envío | Velocidad de recepción | Uso general de CPU |
|---|
| Directo (1 flujo) | 3.00 Gbits/seg | 2.37 Gbits/seg | 25% (1 núcleo al 100%) |
| Phantun (1 flujo) | 1.30 Gbits/seg | 1.20 Gbits/seg | 60% (1 núcleo al 100%, 3 núcleos al 50%) |
udp2raw (cipher-mode=none auth-mode=none disable-anti-replay) (1 flujo) | 1.30 Gbits/seg | 715 Mbits/seg | 40% (1 núcleo al 100%, 1 núcleo al 50%, 2 núcleos inactivos) |
| Conexión directa (5 flujos) | 5.00 Gbits/seg | 3.64 Gbits/seg | 25% (1 núcleo al 100%) |
| Phantun (5 flujos) | 5.00 Gbits/seg | 2.38 Gbits/seg | 95% (todos los núcleos utilizados) |
udp2raw (cipher-mode=none auth-mode=none disable-anti-replay) (5 flujos) | 5.00 Gbits/seg | 770 Mbits/seg | 50% (2 núcleos al 100%) |
| Phantun | udp2raw |
|---|
| Ofuscación UDP sobre FakeTCP | ✅ | ✅ |
| Ofuscación UDP sobre ICMP | ❌ | ✅ |
| Ofuscación UDP sobre UDP | ❌ | ✅ |
| Multihilo | ✅ | ❌ |
| Rendimiento | Mejor | Bueno |
| Modo de capa 3 | Interfaz TUN | Raw sockets + BPF |
| Sobrecarga de MTU del túnel | 12 bytes | 44 bytes |
| Conexiones TCP separadas para cada conexión UDP | Cliente/Servidor | Solo servidor |
| Antirreproducción, cifrado | ❌ | ✅ |
| IPv6 | ✅ | ✅ |