dndx/phantunTrasforma flussi UDP in (falsi) flussi TCP che possono attraversare firewall/NAT di Layer 3 e Layer 4 (NAPT).
Un obfuscator UDP-to-TCP leggero e veloce.
Rust fornisce solo supporto Tier 3 per le piattaforme basate su MIPS dal 2023. Le build MIPS di Phantun sono quindi compilate usando il toolchain nightly di Rust e fornite solo su base del miglior sforzo.
Phantun è un progetto che offusca pacchetti UDP in connessioni TCP. Mira a raggiungere le massime prestazioni con il minimo overhead di elaborazione e incapsulamento.
È comunemente utilizzato in ambienti dove UDP è bloccato/limitato ma TCP è permesso.
Phantun converte semplicemente un flusso di pacchetti UDP in pacchetti di flusso TCP offuscati. Lo stack TCP utilizzato da Phantun è progettato per superare la maggior parte dei firewall/NAT stateful/stateless L3/L4. Non sarà in grado di superare proxy L7. Tuttavia, il vantaggio di questo approccio è che nessuno dei comuni killer di prestazioni UDP su TCP come ritrasmissioni e controllo di flusso si verificherà. Le proprietà sottostanti di UDP, come la consegna fuori ordine, sono totalmente preservate anche se la connessione finisce per apparire come una connessione TCP dal punto di vista dei firewall/NAT.
Phantun significa Phantom TUN, poiché è un offuscatore per traffico UDP che fa abbastanza lavoro per farlo passare attraverso firewall/NAT stateful come pacchetti TCP.
Phantun è scritto in Rust 100% sicuro. È stato ottimizzato estensivamente per scalare bene su sistemi multi-core e non ha problemi a saturare tutte le risorse CPU disponibili su una connessione veloce. Vedere la sezione Prestazioni per i risultati dei benchmark.
Nell'esempio seguente si assume che il Server Phantun ascolti le connessioni Client Phantun in entrata sulla
porta 4567 (opzione --local per il server) e inoltri i pacchetti UDP al server UDP su 127.0.0.1:1234
(opzione --remote per il server).
Si assume inoltre che il Client Phantun ascolti i pacchetti UDP in entrata su
127.0.0.1:1234 (opzione --local per il client) e si connetta al Server Phantun su 10.0.0.1:4567
(opzione --remote per il client).
Phantun crea un'interfaccia TUN sia per il Client che per il Server. Per il Client, Phantun assegna a sé stesso l'indirizzo IP
192.168.200.2 e fcc8::2 di default.
Per il Server, assegna 192.168.201.2 e fcc9::2 di default. Pertanto, il kernel deve avere
l'inoltro IPv4/IPv6 abilitato e vanno configurate regole iptables/nftables appropriate per NAT tra l'indirizzo
della scheda di rete fisica e l'indirizzo dell'interfaccia Tun di Phantun.
È possibile personalizzare il nome dell'interfaccia Tun creata da Phantun e gli indirizzi assegnati. Si prega di
eseguire l'eseguibile con le opzioni -h per vedere come modificarli.
Un altro modo per comprendere questa topologia di rete (si veda il diagramma sopra per un'illustrazione di questa topologia):
Il Client Phantun è come una macchina con indirizzo IP privato (192.168.200.2/fcc8::2) dietro un router.
Affinché possa raggiungere Internet, è necessario eseguire SNAT dell'indirizzo IP privato prima che il suo traffico
lasci la scheda di rete.
Il Server Phantun è come un server con indirizzo IP privato (192.168.201.2/fcc9::2) dietro un router.
Per accedervi da Internet, è necessario eseguire DNAT sulla porta di ascolto sul router
e cambiare l'indirizzo IP di destinazione con quello su cui il server ascolta le connessioni in entrata.
In questi casi, la macchina/iptables che esegue Phantun agisce come il "router" che permette a Phantun di comunicare con l'esterno usando i suoi indirizzi IP privati.
A partire da Phantun v0.4.1, IPv6 è completamente supportato sia per il lato TCP che UDP.
Per specificare un indirizzo IPv6, usare il seguente formato: [::1]:1234 nelle
opzioni della riga di comando. È anche supportata la risoluzione di record AAAA. Si prega di eseguire il programma
con -h per vedere le opzioni dettagliate su come controllare il comportamento IPv6.
Modificare /etc/sysctl.conf, aggiungere net.ipv4.ip_forward=1 ed eseguire sudo sysctl -p /etc/sysctl.conf.
Dovrà essere impostato anche net.ipv6.conf.all.forwarding=1.
Il Client necessita semplicemente di SNAT abilitato sull'interfaccia fisica per tradurre l'indirizzo di Phantun in uno utilizzabile sulla rete fisica. Questo può essere fatto semplicemente con il masquerading.
Nota: cambiare eth0 con il nome effettivo dell'interfaccia fisica
table inet nat {
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
iifname tun0 oif eth0 masquerade
}
}
Nota: La regola sopra usa inet come tipo di famiglia di tabella, quindi è compatibile con
entrambi gli utilizzi IPv4 e IPv6.
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Il Server deve eseguire DNAT sulla porta di ascolto TCP all'indirizzo dell'interfaccia TUN di Phantun.
Nota: cambiare eth0 con il nome effettivo dell'interfaccia fisica e 4567 con
il numero di porta TCP effettivo utilizzato dal server 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
È sconsigliato eseguire applicazioni esposte alla rete come utente root. Phantun può essere eseguito completamente
come utente non-root con la capacità cap_net_admin.
sudo setcap cap_net_admin=+pe phantun_server
sudo setcap cap_net_admin=+pe phantun_client
Nota: Eseguire l'eseguibile Phantun con l'opzione -h per vedere tutte le opzioni dettagliate.
Nota: 4567 è la porta TCP su cui Phantun deve ascoltare e deve corrispondere alla regola DNAT
specificata sopra. 127.0.0.1:1234 è il Server UDP a cui connettersi per nuove connessioni.
RUST_LOG=info /usr/local/bin/phantun_server --local 4567 --remote 127.0.0.1:1234
Oppure usare un nome host con --remote:
RUST_LOG=info /usr/local/bin/phantun_server --local 4567 --remote example.com:1234
Nota: Il Server assegna di default sia l'indirizzo privato IPv4 che IPv6 all'interfaccia Tun. Se non si desidera utilizzare IPv6, è sufficiente saltare la creazione della regola DNAT IPv6 sopra e la presenza dell'indirizzo IPv6 sull'interfaccia Tun non dovrebbe avere effetti collaterali sul server.
Nota: 127.0.0.1:1234 è l'indirizzo UDP e la porta su cui Phantun deve ascoltare. 10.0.0.1:4567 è
il Server Phantun a cui connettersi.
RUST_LOG=info /usr/local/bin/phantun_client --local 127.0.0.1:1234 --remote 10.0.0.1:4567
Oppure usare un nome 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
È supportato anche il nome di dominio con record AAAA.
Phantun mira a mantenere l'overhead di tunneling al minimo. L'overhead rispetto a un pacchetto UDP semplice è il seguente (usando IPv4 come esempio):
Pacchetto UDP standard: 20 byte header IP + 8 byte header UDP = 28 byte
Pacchetto offuscato: 20 byte header IP + 20 byte header TCP = 40 byte
Nota che Phantun non aggiunge alcun header aggiuntivo oltre agli header IP e TCP per superare l'ispezione stateful dei pacchetti!
Overhead aggiuntivo di Phantun: 12 byte. In altre parole, quando si utilizza Phantun, il payload utilizzabile per
il pacchetto UDP è ridotto di 12 byte. Questo è l'overhead minimo possibile per questo tipo di
offuscamento.
Per coloro che utilizzano Phantun per incapsulare pacchetti UDP di WireGuard®, ecco alcune linee guida per determinare il MTU corretto da usare per l'interfaccia WireGuard.
MTU WireGuard = MTU collegamento - header IPv4 (20 byte) - header TCP (20 byte) - overhead WireGuard (32 byte)
oppure
MTU WireGuard = MTU collegamento - header IPv6 (40 byte) - header TCP (20 byte) - overhead WireGuard (32 byte)
Ad esempio, per un collegamento di rete con MTU 1500 byte, il MTU dell'interfaccia WireGuard dovrebbe essere impostato come:
IPv4: 1500 (MTU collegamento) - 20 - 20 - 32 = 1428 byte
IPv6: 1500 (MTU collegamento) - 40 - 20 - 32 = 1408 byte
Il pacchetto dati TCP Phantun risultante sarà di 1500 byte, che non supera il MTU dell'interfaccia di 1500.
Si prega di notare che Phantun non può funzionare correttamente se
la dimensione del pacchetto supera quella del MTU del collegamento, poiché Phantun non esegue alcuna frammentazione IP
e riassemblaggio. Per lo stesso motivo, Phantun imposta sempre il bit DF (Don't Fragment)
nell'header IP per impedire ai dispositivi intermedi di eseguire qualsiasi frammentazione sul pacchetto.
È anche fortemente raccomandato utilizzare lo stesso MTU dell'interfaccia per entrambe le estremità di un tunnel WireGuard, altrimenti potrebbero verificarsi perdite di pacchetti impreviste e questi problemi sono generalmente molto difficili da diagnosticare.
Sebbene lo stack TCP sia abbastanza stabile, l'aspettativa generale è che si debbano eseguire versioni minori uguali del Server/Client di Phantun su entrambe le estremità per garantire la massima compatibilità.
Per gli utenti che desiderano utilizzare la libreria fake-tcp all'interno del proprio progetto, fare riferimento alla documentazione per la libreria su:
https://docs.rs/fake-tcp.
Le prestazioni sono state testate su 2 istanze AWS t4g.xlarge con 4 vCPU e 5 Gb/s NIC su LAN. È stato utilizzato nftables per reindirizzare
il flusso UDP di iperf3 attraverso il tunnel Phantun/udp2raw tra le due istanze di test e il MTU è stato regolato per evitare frammentazione.
Sono state utilizzate Phantun v0.3.2 e udp2raw_arm_asm_aes 20200818.0. Queste erano le ultime release di entrambi i progetti ad aprile 2022.
Comando di test: iperf3 -c <IP> -p <PORT> -R -u -l 1400 -b 1000m -t 30 -P 5
| Modalità | Velocità invio | Velocità ricezione | Utilizzo CPU totale |
|---|---|---|---|
| Diretta (1 flusso) | 3.00 Gbits/sec | 2.37 Gbits/sec | 25% (1 core al 100%) |
| Phantun (1 flusso) | 1.30 Gbits/sec | 1.20 Gbits/sec | 60% (1 core al 100%, 3 core al 50%) |
udp2raw (cipher-mode=none auth-mode=none disable-anti-replay) (1 flusso) | 1.30 Gbits/sec | 715 Mbits/sec | 40% (1 core al 100%, 1 core al 50%, 2 core in idle) |
| Connessione diretta (5 flussi) | 5.00 Gbits/sec | 3.64 Gbits/sec | 25% (1 core al 100%) |
| Phantun (5 flussi) | 5.00 Gbits/sec | 2.38 Gbits/sec | 95% (tutti i core utilizzati) |
udp2raw (cipher-mode=none auth-mode=none disable-anti-replay) (5 flussi) | 5.00 Gbits/sec | 770 Mbits/sec | 50% (2 core al 100%) |
Articolo su alcune delle tecniche utilizzate in Phantun per ottenere questo risultato di prestazioni: Writing Highly Efficient UDP Server in Rust.
udp2raw è un altro progetto popolare di @wangyu- molto simile a ciò che Phantun può fare. In effetti ho tratto ispirazione per Phantun da udp2raw. La ragione principale per sviluppare Phantun è la mancanza di prestazioni durante l'esecuzione di udp2raw (specialmente su sistemi multi-core come Raspberry Pi). Tuttavia, l'obiettivo non è mai stato quello di essere completo come udp2raw e supportare solo i casi d'uso più comuni. In particolare, la modalità UDP su ICMP e UDP su UDP non sono supportate, non c'è anti-replay né supporto per la crittografia. Il vantaggio è prestazioni molto migliori nel complesso e meno overhead MTU grazie all'assenza di header aggiuntivi all'interno del payload TCP.
Ecco una rapida panoramica del confronto tra i due per aiutarvi a scegliere:
| Phantun | udp2raw | |
|---|---|---|
| Offuscamento UDP su FakeTCP | ✅ | ✅ |
| Offuscamento UDP su ICMP | ❌ | ✅ |
| Offuscamento UDP su UDP | ❌ | ✅ |
| Multi-thread | ✅ | ❌ |
| Throughput | Migliore | Buono |
| Modalità Layer 3 | Interfaccia TUN | Raw socket + BPF |
| Overhead MTU tunneling | 12 byte | 44 byte |
| Connessioni TCP separate per ogni connessione UDP | Client/Server | Solo Server |
| Anti-replay, crittografia | ❌ | ✅ |
| IPv6 | ✅ | ✅ |
Copyright 2021-2025 Datong Sun ([email protected])
Concesso in licenza secondo l'Apache License, Versione 2.0 <LICENSE-APACHE o https://www.apache.org/licenses/LICENSE-2.0> o la licenza MIT <LICENSE-MIT o https://opensource.org/licenses/MIT, a tua scelta. I file del progetto non possono essere copiati, modificati o distribuiti se non in conformità con tali termini.