dndx/phantunWandelt UDP-Streams in (gefälschte) TCP-Streams um, die durch Layer 3 & Layer 4 (NAPT) Firewalls/NATs hindurchgehen können.
Ein leichter und schneller UDP-zu-TCP-Verschleierer.
Rust bietet für MIPS-basierte Plattformen nur Tier-3-Unterstützung seit 2023. Phantuns MIPS-Builds werden daher mit dem nächtlichen Rust-Toolchain erstellt und nur auf bestmöglicher Basis bereitgestellt.
Phantun ist ein Projekt, das UDP-Pakete in TCP-Verbindungen verschleiert. Es zielt darauf ab, maximale Leistung bei minimalem Verarbeitungs- und Kapselungsaufwand zu erreichen.
Es wird häufig in Umgebungen eingesetzt, in denen UDP blockiert/gedrosselt wird, TCP jedoch erlaubt ist.
Phantun wandelt einfach einen Strom von UDP-Paketen in verschleierte TCP-Stream-Pakete um. Der von Phantun verwendete TCP-Stack ist so konzipiert, dass er die meisten L3/L4-zustandsbehafteten/zustandslosen Firewalls/NAT-Geräte passieren kann. Er wird nicht in der Lage sein, L7-Proxys zu passieren. Der Vorteil dieses Ansatzes ist jedoch, dass keiner der üblichen Leistungskiller von UDP über TCP, wie Neuübertragungen und Flusskontrolle, auftritt. Die zugrunde liegenden UDP-Eigenschaften wie außerordentliche Zustellung bleiben vollständig erhalten, auch wenn die Verbindung aus der Perspektive von Firewalls/NAT-Geräten wie eine TCP-Verbindung aussieht.
Phantun bedeutet Phantom TUN, da es ein Verschleierer für UDP-Verkehr ist, der gerade genug Arbeit leistet, um ihn als TCP-Pakete durch zustandsbehaftete Firewalls/NATs zu bringen.
Phantun ist zu 100 % in sicherem Rust geschrieben. Es wurde umfassend optimiert, um auf Multi-Core-Systemen gut zu skalieren, und hat keine Probleme damit, alle verfügbaren CPU-Ressourcen bei einer schnellen Verbindung auszulasten. Siehe den Abschnitt Leistung für Benchmark-Ergebnisse.
Für das folgende Beispiel wird angenommen, dass der Phantun-Server auf eingehende Phantun-Client-Verbindungen auf
Port 4567 hört (die --local-Option für den Server) und UDP-Pakete an den UDP-Server unter 127.0.0.1:1234 weiterleitet
(die --remote-Option für den Server).
Es wird auch angenommen, dass der Phantun-Client auf eingehende UDP-Pakete unter
127.0.0.1:1234 hört (die --local-Option für den Client) und sich mit dem Phantun-Server unter 10.0.0.1:4567 verbindet
(die --remote-Option für den Client).
Phantun erstellt ein TUN-Interface sowohl für den Client als auch für den Server. Für den Client weist sich Phantun standardmäßig die IP-Adresse
192.168.200.2 und fcc8::2 zu.
Für den Server weist es standardmäßig 192.168.201.2 und fcc9::2 zu. Daher muss Ihr Kernel
IPv4/IPv6-Weiterleitung aktiviert haben und entsprechende iptables/nftables-Regeln für NAT zwischen Ihrer physischen
NIC-Adresse und der Adresse des Phantun-Tun-Interfaces eingerichtet sein.
Sie können den Namen des von Phantun erstellten Tun-Interfaces und die zugewiesenen Adressen anpassen. Bitte
führen Sie die ausführbare Datei mit der Option -h aus, um zu sehen, wie Sie diese ändern können.
Eine weitere Möglichkeit, diese Netzwerktopologie zu verstehen (siehe das obige Diagramm für eine Veranschaulichung dieser Topologie):
Der Phantun-Client ist wie eine Maschine mit privater IP-Adresse (192.168.200.2/fcc8::2) hinter einem Router.
Damit er das Internet erreichen kann, müssen Sie die private IP-Adresse SNAT-en, bevor ihr Verkehr
die NIC verlässt.
Der Phantun-Server ist wie ein Server mit privater IP-Adresse (192.168.201.2/fcc9::2) hinter einem Router.
Um ihn aus dem Internet zu erreichen, müssen Sie seinen listening Port auf dem Router DNAT-en
und die Ziel-IP-Adresse auf die Adresse ändern, auf der der Server auf eingehende Verbindungen hört.
In diesen Fällen fungiert die Maschine/die iptables, die Phantun ausführt, als der "Router", der es Phantun ermöglicht, mit der Außenwelt über seine privaten IP-Adressen zu kommunizieren.
Seit Phantun v0.4.1 wird IPv6 sowohl für die TCP- als auch für die UDP-Seite vollständig unterstützt.
Um eine IPv6-Adresse anzugeben, verwenden Sie das folgende Format: [::1]:1234 mit
den Befehlszeilenoptionen. Das Auflösen von AAAA-Einträgen wird ebenfalls unterstützt. Bitte führen Sie das Programm
mit -h aus, um detaillierte Optionen zur Steuerung des IPv6-Verhaltens zu sehen.
Bearbeiten Sie /etc/sysctl.conf, fügen Sie net.ipv4.ip_forward=1 hinzu und führen Sie sudo sysctl -p /etc/sysctl.conf aus.
net.ipv6.conf.all.forwarding=1 muss ebenfalls gesetzt werden.
Der Client benötigt lediglich SNAT auf dem physischen Interface, um Phantuns Adresse in eine zu übersetzen, die im physischen Netzwerk verwendet werden kann. Dies kann einfach mit Masquerade erfolgen.
Hinweis: Ändern Sie eth0 in den tatsächlichen Namen des physischen Interfaces.
table inet nat {
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
iifname tun0 oif eth0 masquerade
}
}
Hinweis: Die obige Regel verwendet inet als Tabellenfamilientyp, daher ist sie sowohl mit
IPv4 als auch IPv6 kompatibel.
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Der Server muss den TCP-Listening-Port auf die Adresse des Phantun-TUN-Interfaces DNAT-en.
Hinweis: Ändern Sie eth0 in den tatsächlichen Namen des physischen Interfaces und 4567 in
die tatsächliche TCP-Portnummer, die vom Phantun-Server verwendet wird.
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
Es ist nicht ratsam, netzwerkorientierte Anwendungen als Root-Benutzer auszuführen. Phantun kann vollständig
als Nicht-Root-Benutzer mit der Fähigkeit cap_net_admin ausgeführt werden.
sudo setcap cap_net_admin=+pe phantun_server
sudo setcap cap_net_admin=+pe phantun_client
Hinweis: Führen Sie die Phantun-Ausführungsdatei mit der Option -h aus, um alle detaillierten Optionen zu sehen.
Hinweis: 4567 ist der TCP-Port, auf dem Phantun hören soll, und muss mit der oben angegebenen DNAT-Regel
übereinstimmen. 127.0.0.1:1234 ist der UDP-Server, mit dem für neue Verbindungen verbunden wird.
RUST_LOG=info /usr/local/bin/phantun_server --local 4567 --remote 127.0.0.1:1234
Oder verwenden Sie den Hostnamen mit --remote:
RUST_LOG=info /usr/local/bin/phantun_server --local 4567 --remote example.com:1234
Hinweis: Der Server weist standardmäßig sowohl eine IPv4- als auch eine IPv6-Privatadresse dem Tun-Interface zu. Wenn Sie IPv6 nicht verwenden möchten, können Sie einfach die obige IPv6-DNAT-Regel weglassen und das Vorhandensein der IPv6-Adresse auf dem Tun-Interface sollte keine Nebenwirkungen auf den Server haben.
Hinweis: 127.0.0.1:1234 ist die UDP-Adresse und der Port, auf dem Phantun hören soll. 10.0.0.1:4567 ist
der Phantun-Server, mit dem verbunden werden soll.
RUST_LOG=info /usr/local/bin/phantun_client --local 127.0.0.1:1234 --remote 10.0.0.1:4567
Oder verwenden Sie den Hostnamen mit --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
Domainnamen mit AAAA-Eintrag werden ebenfalls unterstützt.
Phantun zielt darauf ab, den Tunneling-Overhead minimal zu halten. Der Overhead im Vergleich zu einem normalen UDP-Paket ist wie folgt (hier als Beispiel mit IPv4):
Standard-UDP-Paket: 20 Byte IP-Header + 8 Byte UDP-Header = 28 Bytes
Verschleiertes Paket: 20 Byte IP-Header + 20 Byte TCP-Header = 40 Bytes
Beachten Sie, dass Phantun außer IP- und TCP-Headern keine zusätzlichen Header hinzufügt, um die zustandsbehaftete Paketinspektion zu passieren!
Phantuns zusätzlicher Overhead: 12 Bytes. Mit anderen Worten: Bei Verwendung von Phantun reduziert sich die nutzbare Nutzlast für
ein UDP-Paket um 12 Bytes. Dies ist der minimale Overhead, der bei einer solchen Art der Verschleierung möglich ist.
Für Personen, die Phantun zum Tunneln von WireGuard®-UDP-Paketen verwenden, hier einige Richtlinien zur Bestimmung der korrekten MTU für Ihr WireGuard-Interface.
WireGuard MTU = Link-MTU - IPv4-Header (20 Bytes) - TCP-Header (20 Bytes) - WireGuard-Overhead (32 Bytes)
oder
WireGuard MTU = Link-MTU - IPv6-Header (40 Bytes) - TCP-Header (20 Bytes) - WireGuard-Overhead (32 Bytes)
Zum Beispiel sollte für eine Netzwerkverbindung mit 1500 Bytes MTU die WireGuard-Interface-MTU wie folgt eingestellt werden:
IPv4: 1500 (Link-MTU) - 20 - 20 - 32 = 1428 Bytes
IPv6: 1500 (Link-MTU) - 40 - 20 - 32 = 1408 Bytes
Das resultierende Phantun-TCP-Datenpaket wird 1500 Bytes groß sein, was die Interface-MTU von 1500 nicht überschreitet.
Bitte beachten Sie: Phantun kann nicht korrekt funktionieren, wenn die Paketgröße die der Link-MTU überschreitet, da Phantun keine IP-Fragmentierung
und -Wiederzusammenstellung durchführt. Aus dem gleichen Grund setzt Phantun immer das DF (Don't Fragment)-Bit
im IP-Header, um zu verhindern, dass zwischengeschaltete Geräte eine Fragmentierung des Pakets durchführen.
Es wird auch dringend empfohlen, für beide Enden eines WireGuard-Tunnels die gleiche Interface-MTU zu verwenden, da sonst unerwarteter Paketverlust auftreten kann und diese Probleme im Allgemeinen sehr schwer zu diagnostizieren sind.
Obwohl der TCP-Stack recht stabil ist, wird allgemein erwartet, dass Sie auf beiden Enden dieselben Nebenversionen des Phantun-Servers/-Clients ausführen, um maximale Kompatibilität zu gewährleisten.
Für Benutzer, die die fake-tcp-Bibliothek in ihrem eigenen Projekt verwenden möchten, finden Sie die Dokumentation für die Bibliothek unter:
https://docs.rs/fake-tcp.
Die Leistung wurde auf zwei AWS t4g.xlarge-Instanzen mit 4 vCPUs und 5 Gb/s NIC über LAN getestet. nftables wurde verwendet, um den
UDP-Stream von iperf3 durch den Phantun/udp2raw-Tunnel zwischen zwei Testinstanzen umzuleiten, und die MTU wurde angepasst, um Fragmentierung zu vermeiden.
Phantun v0.3.2 und udp2raw_arm_asm_aes 20200818.0 wurden verwendet. Dies waren die neuesten Veröffentlichungen beider Projekte Stand April 2022.
Testbefehl: iperf3 -c <IP> -p <PORT> -R -u -l 1400 -b 1000m -t 30 -P 5
Ein Bericht über einige der in Phantun verwendeten Techniken zur Erzielung dieses Leistungsergebnisses: Writing Highly Efficient UDP Server in Rust.
udp2raw ist ein weiteres beliebtes Projekt von @wangyu-, das dem, was Phantun kann, sehr ähnlich ist. Tatsächlich habe ich Inspirationen für Phantun von udp2raw genommen. Der Hauptgrund für die Entwicklung von Phantun ist die mangelnde Leistung beim Ausführen von udp2raw (insbesondere auf Multi-Core-Systemen wie dem Raspberry Pi). Das Ziel ist jedoch nie, den Funktionsumfang von udp2raw zu erreichen, sondern nur die häufigsten Anwendungsfälle zu unterstützen. Insbesondere werden UDP über ICMP und UDP über UDP-Modi nicht unterstützt, und es gibt weder Anti-Replay noch Verschlüsselung. Der Vorteil davon ist eine insgesamt viel bessere Leistung und weniger MTU-Overhead, da keine zusätzlichen Header innerhalb der TCP-Nutzlast vorhanden sind.
Hier eine kurze Übersicht zum Vergleich der beiden, um Ihnen bei der Auswahl zu helfen:
Copyright 2021-2025 Datong Sun ([email protected])
Lizenziert unter der Apache License, Version 2.0 <LICENSE-APACHE oder https://www.apache.org/licenses/LICENSE-2.0> oder der MIT-Lizenz <LICENSE-MIT oder https://opensource.org/licenses/MIT, nach Ihrer Wahl. Dateien im Projekt dürfen nicht kopiert, modifiziert oder verbreitet werden, außer gemäß diesen Bedingungen.
| Modus | Sende-Geschwindigkeit | Empfangs-Geschwindigkeit | Gesamt-CPU-Auslastung |
|---|
| Direkt (1 Stream) | 3,00 Gbit/s | 2,37 Gbit/s | 25% (1 Kern bei 100%) |
| Phantun (1 Stream) | 1,30 Gbit/s | 1,20 Gbit/s | 60% (1 Kern bei 100%, 3 Kerne bei 50%) |
udp2raw (cipher-mode=none auth-mode=none disable-anti-replay) (1 Stream) | 1,30 Gbit/s | 715 Mbit/s | 40% (1 Kern bei 100%, 1 Kern bei 50%, 2 Kerne im Leerlauf) |
| Direkte Verbindung (5 Streams) | 5,00 Gbit/s | 3,64 Gbit/s | 25% (1 Kern bei 100%) |
| Phantun (5 Streams) | 5,00 Gbit/s | 2,38 Gbit/s | 95% (alle Kerne ausgelastet) |
udp2raw (cipher-mode=none auth-mode=none disable-anti-replay) (5 Streams) | 5,00 Gbit/s | 770 Mbit/s | 50% (2 Kerne bei 100%) |
| Phantun | udp2raw |
|---|
| UDP über FakeTCP-Verschleierung | ✅ | ✅ |
| UDP über ICMP-Verschleierung | ❌ | ✅ |
| UDP über UDP-Verschleierung | ❌ | ✅ |
| Multithreaded | ✅ | ❌ |
| Durchsatz | Besser | Gut |
| Layer-3-Modus | TUN-Interface | Roh-Sockets + BPF |
| Tunneling-MTU-Overhead | 12 Bytes | 44 Bytes |
| Separate TCP-Verbindungen für jede UDP-Verbindung | Client/Server | Nur Server |
| Anti-Replay, Verschlüsselung | ❌ | ✅ |
| IPv6 | ✅ | ✅ |