dndx/phantunTransforma fluxo UDP em fluxos TCP (falsos) que podem atravessar firewalls/NATs de Camada 3 e Camada 4 (NAPT).
Um ofuscador UDP para TCP leve e rápido.
O Rust fornece apenas suporte Tier 3 para plataformas baseadas em MIPS desde 2023. As compilações MIPS do Phantun são, portanto, construídas usando a toolchain nightly do Rust e fornecidas apenas com o melhor esforço.
Phantun é um projeto que ofusca pacotes UDP em conexões TCP. Ele visa alcançar o máximo desempenho com o mínimo de processamento e sobrecarga de encapsulamento.
É comumente usado em ambientes onde o UDP é bloqueado/limitado, mas o TCP é permitido.
Phantun simplesmente converte um fluxo de pacotes UDP em pacotes de fluxo TCP ofuscados. A pilha TCP usada pelo Phantun é projetada para atravessar a maioria dos firewalls/dispositivos NAT com estado/sem estado L3/L4. Ele não será capaz de atravessar proxies L7. No entanto, a vantagem dessa abordagem é que nenhum dos problemas comuns de desempenho do UDP sobre TCP, como retransmissões e controle de fluxo, ocorrerá. As propriedades subjacentes do UDP, como entrega fora de ordem, são totalmente preservadas, mesmo que a conexão acabe parecendo uma conexão TCP do ponto de vista de firewalls/dispositivos NAT.
Phantun significa Phantom TUN, pois é um ofuscador de tráfego UDP que faz apenas o trabalho necessário para fazê-lo passar por firewalls/NATs com estado como pacotes TCP.
Phantun é escrito em Rust 100% seguro. Ele foi extensivamente otimizado para escalar bem em sistemas multi-core e não tem problema em saturar todos os recursos de CPU disponíveis em uma conexão rápida. Veja a seção Desempenho para resultados de benchmarks.
Para o exemplo abaixo, assume-se que o Servidor Phantun escuta conexões de entrada do Cliente Phantun na porta 4567 (a opção --local para o servidor), e encaminha pacotes UDP para o servidor UDP em 127.0.0.1:1234 (a opção --remote para o servidor).
Assume-se também que o Cliente Phantun escuta pacotes UDP de entrada em 127.0.0.1:1234 (a opção --local para o cliente) e se conecta ao Servidor Phantun em 10.0.0.1:4567 (a opção --remote para o cliente).
Phantun cria uma interface TUN tanto para o Cliente quanto para o Servidor. Para o Cliente, o Phantun atribui a si mesmo os endereços IP 192.168.200.2 e fcc8::2 por padrão. Para o Servidor, atribui 192.168.201.2 e fcc9::2 por padrão. Portanto, seu kernel deve ter o encaminhamento IPv4/IPv6 habilitado e configurar regras apropriadas de iptables/nftables para NAT entre o endereço da sua placa de rede física e o endereço da interface Tun do Phantun.
Você pode personalizar o nome da interface Tun criada pelo Phantun e os endereços atribuídos. Execute o executável com a opção -h para ver como alterá-los.
Outra forma de ajudar a entender essa topologia de rede (veja o diagrama acima para uma ilustração desta topologia):
O Cliente Phantun é como uma máquina com endereço IP privado (192.168.200.2/fcc8::2) atrás de um roteador. Para que ele alcance a Internet, você precisará fazer SNAT do endereço IP privado antes que seu tráfego saia da placa de rede.
O Servidor Phantun é como um servidor com endereço IP privado (192.168.201.2/fcc9::2) atrás de um roteador. Para acessá-lo a partir da Internet, você precisa fazer DNAT da porta de escuta no roteador e alterar o endereço IP de destino para onde o servidor está escutando conexões de entrada.
Nesses casos, a máquina/iptables executando o Phantun atua como o 'roteador' que permite ao Phantun se comunicar com o exterior usando seus endereços IP privados.
A partir do Phantun v0.4.1, o IPv6 é totalmente suportado tanto para os lados TCP quanto UDP. Para especificar um endereço IPv6, use o seguinte formato: [::1]:1234 com as opções da linha de comando. A resolução de registros AAAA também é suportada. Execute o programa com -h para ver opções detalhadas sobre como controlar o comportamento IPv6.
Edite /etc/sysctl.conf, adicione net.ipv4.ip_forward=1 e execute sudo sysctl -p /etc/sysctl.conf.
net.ipv6.conf.all.forwarding=1 também precisará ser configurado.
O Cliente simplesmente precisa ter o SNAT habilitado na interface física para traduzir o endereço do Phantun em um que possa ser usado na rede física. Isso pode ser feito simplesmente com masquerade.
Nota: altere eth0 para o nome real da interface física
table inet nat {
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
iifname tun0 oif eth0 masquerade
}
}
Nota: A regra acima usa inet como tipo de família de tabela, portanto é compatível com uso IPv4 e IPv6.
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
O Servidor precisa fazer DNAT da porta de escuta TCP para o endereço da interface TUN do Phantun.
Nota: altere eth0 para o nome real da interface física e 4567 para o número real da porta TCP usada pelo 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
Não é aconselhável executar aplicações voltadas para a rede como usuário root. O Phantun pode ser executado completamente como usuário não-root com a capacidade cap_net_admin.
sudo setcap cap_net_admin=+pe phantun_server
sudo setcap cap_net_admin=+pe phantun_client
Nota: Execute o executável Phantun com a opção -h para ver todas as opções detalhadas.
Nota: 4567 é a porta TCP na qual o Phantun deve escutar e deve corresponder à regra DNAT especificada acima. 127.0.0.1:1234 é o servidor UDP ao qual se conectar para novas conexões.
RUST_LOG=info /usr/local/bin/phantun_server --local 4567 --remote 127.0.0.1:1234
Ou use nome de host com --remote:
RUST_LOG=info /usr/local/bin/phantun_server --local 4567 --remote example.com:1234
Nota: O servidor atribui por padrão endereços privados IPv4 e IPv6 à interface Tun. Se você não deseja usar IPv6, pode simplesmente pular a criação da regra DNAT IPv6 acima e a presença do endereço IPv6 na interface Tun não deve ter efeito colateral no servidor.
Nota: 127.0.0.1:1234 é o endereço e porta UDP nos quais o Phantun deve escutar. 10.0.0.1:4567 é o Servidor Phantun ao qual se conectar.
RUST_LOG=info /usr/local/bin/phantun_client --local 127.0.0.1:1234 --remote 10.0.0.1:4567
Ou use nome de host com --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
Nome de domínio com registro AAAA também é suportado.
Phantun visa manter a sobrecarga de tunelamento no mínimo. A sobrecarga comparada a um pacote UDP simples é a seguinte (usando IPv4 abaixo como exemplo):
Pacote UDP padrão: 20 bytes de cabeçalho IP + 8 bytes de cabeçalho UDP = 28 bytes
Pacote ofuscado: 20 bytes de cabeçalho IP + 20 bytes de cabeçalho TCP = 40 bytes
Note que o Phantun não adiciona nenhum cabeçalho adicional além dos cabeçalhos IP e TCP para passar pela inspeção de pacotes com estado!
A sobrecarga adicional do Phantun: 12 bytes. Em outras palavras, ao usar o Phantun, a carga útil utilizável do pacote UDP é reduzida em 12 bytes. Esta é a sobrecarga mínima possível ao fazer esse tipo de ofuscação.
Para pessoas que usam o Phantun para tunelar pacotes UDP WireGuard®, aqui estão algumas diretrizes para descobrir o MTU correto a ser usado na sua interface WireGuard.
MTU do WireGuard = MTU do link - Cabeçalho IPv4 (20 bytes) - Cabeçalho TCP (20 bytes) - Sobrecarga do WireGuard (32 bytes)
ou
MTU do WireGuard = MTU do link - Cabeçalho IPv6 (40 bytes) - Cabeçalho TCP (20 bytes) - Sobrecarga do WireGuard (32 bytes)
Por exemplo, para um link de rede com MTU de 1500 bytes, o MTU da interface WireGuard deve ser definido como:
IPv4: 1500 (MTU do link) - 20 - 20 - 32 = 1428 bytes
IPv6: 1500 (MTU do link) - 40 - 20 - 32 = 1408 bytes
O pacote de dados TCP resultante do Phantun terá 1500 bytes, o que não excede o MTU da interface de 1500.
Por favor, note que o Phantun não pode funcionar corretamente se o tamanho do pacote exceder o MTU do link, pois o Phantun não realiza fragmentação e remontagem IP. Pela mesma razão, o Phantun sempre define o bit DF (Don't Fragment) no cabeçalho IP para evitar que dispositivos intermediários realizem qualquer fragmentação no pacote.
Também é fortemente recomendado usar o mesmo MTU de interface para ambas as extremidades de um túnel WireGuard, ou pode ocorrer perda inesperada de pacotes e esses problemas são geralmente muito difíceis de diagnosticar.
Embora a pilha TCP seja bastante estável, a expectativa geral é que você execute as mesmas versões menores do Servidor/Cliente do Phantun em ambas as extremidades para garantir a máxima compatibilidade.
Para usuários que desejam usar a biblioteca fake-tcp em seu próprio projeto, consulte as documentações da biblioteca em: https://docs.rs/fake-tcp.
O desempenho foi testado em 2 instâncias AWS t4g.xlarge com 4 vCPUs e placa de rede de 5 Gb/s em LAN. nftables foi usado para redirecionar o fluxo UDP do iperf3 para passar pelo túnel Phantun/udp2raw entre duas instâncias de teste e o MTU foi ajustado para evitar fragmentação.
Phantun v0.3.2 e udp2raw_arm_asm_aes 20200818.0 foram usados. Estas eram as versões mais recentes de ambos os projetos em abril de 2022.
Comando de teste: iperf3 -c <IP> -p <PORT> -R -u -l 1400 -b 1000m -t 30 -P 5
| Modo | Velocidade de Envio | Velocidade de Recebimento | Uso Geral da CPU |
|---|---|---|---|
| Direto (1 fluxo) | 3.00 Gbits/sec | 2.37 Gbits/sec | 25% (1 núcleo a 100%) |
| Phantun (1 fluxo) | 1.30 Gbits/sec | 1.20 Gbits/sec | 60% (1 núcleo a 100%, 3 núcleos a 50%) |
udp2raw (cipher-mode=none auth-mode=none disable-anti-replay) (1 fluxo) | 1.30 Gbits/sec | 715 Mbits/sec | 40% (1 núcleo a 100%, 1 núcleo a 50%, 2 núcleos ociosos) |
| Conexão direta (5 fluxos) | 5.00 Gbits/sec | 3.64 Gbits/sec | 25% (1 núcleo a 100%) |
| Phantun (5 fluxos) | 5.00 Gbits/sec | 2.38 Gbits/sec | 95% (todos os núcleos utilizados) |
udp2raw (cipher-mode=none auth-mode=none disable-anti-replay) (5 fluxos) | 5.00 Gbits/sec | 770 Mbits/sec | 50% (2 núcleos a 100%) |
Artigo sobre algumas das técnicas usadas no Phantun para alcançar este resultado de desempenho: Escrevendo um Servidor UDP Altamente Eficiente em Rust.
udp2raw é outro projeto popular de @wangyu- que é muito semelhante ao que o Phantun pode fazer. Na verdade, me inspirei no Phantun a partir do udp2raw. A maior razão para desenvolver o Phantun é a falta de desempenho ao executar o udp2raw (especialmente em sistemas multi-core como Raspberry Pi). No entanto, o objetivo nunca é ser tão completo em recursos quanto o udp2raw e suportar apenas os casos de uso mais comuns. Notavelmente, os modos UDP sobre ICMP e UDP sobre UDP não são suportados e não há suporte para anti-replay ou criptografia. O benefício disso é um desempenho muito melhor em geral e menos sobrecarga de MTU devido à falta de cabeçalhos adicionais dentro da carga útil TCP.
Aqui está uma visão geral rápida da comparação entre os dois para ajudá-lo a escolher:
| Phantun | udp2raw | |
|---|---|---|
| Ofuscação UDP sobre FakeTCP | ✅ | ✅ |
| Ofuscação UDP sobre ICMP | ❌ | ✅ |
| Ofuscação UDP sobre UDP | ❌ | ✅ |
| Multi-thread | ✅ | ❌ |
| Taxa de transferência | Melhor | Boa |
| Modo de camada 3 | Interface TUN | Raw sockets + BPF |
| Sobrecarga de MTU de tunelamento | 12 bytes | 44 bytes |
| Conexões TCP separadas para cada conexão UDP | Cliente/Servidor | Apenas Servidor |
| Anti-replay, criptografia | ❌ | ✅ |
| IPv6 | ✅ | ✅ |
Copyright 2021-2025 Datong Sun ([email protected])
Licenciado sob a Apache License, Versão 2.0 <LICENSE-APACHE ou https://www.apache.org/licenses/LICENSE-2.0> ou a licença MIT <LICENSE-MIT ou https://opensource.org/licenses/MIT>, a seu critério. Os arquivos do projeto não podem ser copiados, modificados ou distribuídos, exceto de acordo com esses termos.