Phantun

Un obfuscateur UDP vers TCP léger et rapide.

Table of Contents

• Phantun
• Dernière version
• Aperçu
• Utilisation
  • 1. Activer le forwarding IP du noyau
  • 2. Ajouter les règles de pare-feu nécessaires
    • Client
      • Avec nftables
      • Avec iptables
    • Serveur
      • Avec nftables
      • Avec iptables
  • 3. Exécuter les binaires Phantun sans privilèges root (Optionnel)
  • 4. Démarrer le démon Phantun
    • Serveur
    • Client
• Surcharge MTU
  • Calcul du MTU pour WireGuard
• Compatibilité des versions
• Documentations
• Performances
• Plans futurs
• Comparaison avec udp2raw
• Licence

Latest release

v0.8.1

Overview

Phantun est un projet qui obfusque les paquets UDP en connexions TCP. Il vise à atteindre des performances maximales avec un minimum de traitement et de surcharge d'encapsulation.

Il est couramment utilisé dans les environnements où l'UDP est bloqué/limite mais où le TCP est autorisé.

Phantun convertit simplement un flux de paquets UDP en paquets de flux TCP obfusqués. La pile TCP utilisée par Phantun est conçue pour traverser la plupart des pare-feu/NAT d'état/de session de couche 3/4. Il ne pourra pas traverser les proxy de couche 7. Cependant, l'avantage de cette approche est qu'aucun des facteurs de performance courants de l'UDP sur TCP, tels que les retransmissions et le contrôle de flux, ne se produira. Les propriétés sous-jacentes de l'UDP, telles que la livraison hors ordre, sont entièrement préservées même si la connexion finit par ressembler à une connexion TCP du point de vue des pare-feu/NAT.

Phantun signifie Phantom TUN, car c'est un obfuscateur pour le trafic UDP qui fait juste assez de travail pour le faire passer à travers un pare-feu/NAT d'état en tant que paquets TCP.

Phantun est écrit en 100% Rust sécurisé. Il a été largement optimisé pour bien passer à l'échelle sur les systèmes multi-cœurs et n'a aucun problème à saturer toutes les ressources CPU disponibles sur une connexion rapide. Voir la section Performances pour les résultats de référence.

Usage

Pour l'exemple ci-dessous, on suppose que le serveur Phantun écoute les connexions entrantes des clients Phantun sur le port 4567 (l'option --local du serveur) et qu'il transmet les paquets UDP au serveur UDP à l'adresse 127.0.0.1:1234 (l'option --remote du serveur).

On suppose également que le client Phantun écoute les paquets UDP entrants sur 127.0.0.1:1234 (l'option --local du client) et se connecte au serveur Phantun à 10.0.0.1:4567 (l'option --remote du client).

Phantun crée une interface TUN à la fois pour le Client et le Serveur. Pour le Client, Phantun s'attribue l'adresse IP 192.168.200.2 et fcc8::2 par défaut. Pour le Serveur, il attribue 192.168.201.2 et fcc9::2 par défaut. Par conséquent, votre noyau doit avoir le forwarding IPv4/IPv6 activé et configurer les règles iptables/nftables appropriées pour le NAT entre l'adresse de votre interface réseau physique et l'adresse de l'interface Tun de Phantun.

Vous pouvez personnaliser le nom de l'interface Tun créée par Phantun et les adresses attribuées. Veuillez exécuter l'exécutable avec les options -h pour voir comment les modifier.

Une autre façon de comprendre cette topologie réseau (veuillez consulter le diagramme ci-dessus pour une illustration de cette topologie) :

Le client Phantun est comme une machine avec une adresse IP privée (192.168.200.2/fcc8::2) derrière un routeur. Pour qu'il puisse atteindre Internet, vous devrez faire du SNAT sur l'adresse IP privée avant que son trafic ne quitte l'interface.

Le serveur Phantun est comme un serveur avec une adresse IP privée (192.168.201.2/fcc9::2) derrière un routeur. Pour y accéder depuis Internet, vous devez faire un DNAT sur son port d'écoute sur le routeur et changer l'adresse IP de destination vers l'adresse où le serveur écoute les connexions entrantes.

Dans ces cas, la machine/iptables exécutant Phantun agit comme le « routeur » qui permet à Phantun de communiquer avec l'extérieur en utilisant ses adresses IP privées.

Depuis Phantun v0.4.1, l'IPv6 est entièrement pris en charge à la fois pour les côtés TCP et UDP. Pour spécifier une adresse IPv6, utilisez le format suivant : [::1]:1234 avec les options de ligne de commande. La résolution d'enregistrement AAAA est également prise en charge. Veuillez exécuter le programme avec -h pour voir les options détaillées sur la façon de contrôler le comportement IPv6.

Retour à la table des matières

1. Enable Kernel IP forwarding

Edit /etc/sysctl.conf, add net.ipv4.ip_forward=1 and run sudo sysctl -p /etc/sysctl.conf.

Retour à la table des matières

2. Add required firewall rules

Client

Le client a simplement besoin que le SNAT soit activé sur l'interface physique pour traduire l'adresse de Phantun en une adresse utilisable sur le réseau physique. Cela peut être fait simplement avec le masquerade.

Remarque : remplacez eth0 par le nom réel de l'interface physique.

Retour à la table des matières

Using nftables

table inet nat {
    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;
        iifname tun0 oif eth0 masquerade
    }
}

Remarque : la règle ci-dessus utilise inet comme type de famille de table, elle est donc compatible avec les utilisations IPv4 et IPv6.

Retour à la table des matières

Using iptables

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Retour à la table des matières

Server

Le serveur a besoin de faire du DNAT sur le port d'écoute TCP vers l'adresse de l'interface TUN de Phantun.

Remarque : remplacez eth0 par le nom réel de l'interface physique et 4567 par le numéro de port TCP réel utilisé par le serveur Phantun.

Retour à la table des matières

Using nftables

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
    }
}

Retour à la table des matières

Using iptables

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

Retour à la table des matières

3. Run Phantun binaries as non-root (Optional)

Il est déconseillé d'exécuter des applications face au réseau en tant qu'utilisateur root. Phantun peut être exécuté entièrement en tant qu'utilisateur non root avec la capacité cap_net_admin.

sudo setcap cap_net_admin=+pe phantun_server
sudo setcap cap_net_admin=+pe phantun_client

Retour à la table des matières

4. Start Phantun daemon

Remarque : Exécutez l'exécutable Phantun avec l'option -h pour voir toutes les options détaillées.

Retour à la table des matières

Server

Remarque : 4567 est le port TCP sur lequel Phantun doit écouter et doit correspondre à la règle DNAT spécifiée ci-dessus. 127.0.0.1:1234 est le serveur UDP auquel se connecter pour les nouvelles connexions.

RUST_LOG=info /usr/local/bin/phantun_server --local 4567 --remote 127.0.0.1:1234

Ou utilisez un nom d'hôte avec --remote :

RUST_LOG=info /usr/local/bin/phantun_server --local 4567 --remote example.com:1234

Remarque : le serveur attribue par défaut à la fois les adresses privées IPv4 et IPv6 à l'interface Tun. Si vous ne souhaitez pas utiliser l'IPv6, vous pouvez simplement ignorer la création de la règle DNAT IPv6 ci-dessus et la présence de l'adresse IPv6 sur l'interface Tun ne devrait avoir aucun effet secondaire pour le serveur.

Retour à la table des matières

Client

Remarque : 127.0.0.1:1234 est l'adresse UDP et le port sur lequel Phantun doit écouter. 10.0.0.1:4567 est le serveur Phantun auquel se connecter.

RUST_LOG=info /usr/local/bin/phantun_client --local 127.0.0.1:1234 --remote 10.0.0.1:4567

Ou utilisez un nom d'hôte avec --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

Retour à la table des matières

MTU overhead

Phantun vise à minimiser la surcharge de tunneling. La surcharge par rapport à un paquet UDP standard est la suivante (en utilisant IPv4 ci-dessous comme exemple) :

Paquet UDP standard : 20 octets d'en-tête IP + 8 octets d'en-tête UDP = 28 octets

Paquet obfusqué : 20 octets d'en-tête IP + 20 octets d'en-tête TCP = 40 octets

Notez que Phantun n'ajoute aucun en-tête supplémentaire autre que les en-têtes IP et TCP pour passer à travers l'inspection stateful !

Surcharge supplémentaire de Phantun : 12 octets. En d'autres termes, lors de l'utilisation de Phantun, la charge utile utilisable pour un paquet UDP est réduite de 12 octets. C'est la surcharge minimale possible lors de ce type d'obfuscation.

Retour à la table des matières

MTU calculation for WireGuard

Pour les personnes qui utilisent Phantun pour tunneliser les paquets UDP de WireGuard®, voici quelques directives pour déterminer le MTU correct à utiliser pour votre interface WireGuard.

WireGuard MTU = MTU de la liaison - En-tête IPv4 (20 octets) - En-tête TCP (20 octets) - Surcharge WireGuard (32 octets)

ou

WireGuard MTU = MTU de la liaison - En-tête IPv6 (40 octets) - En-tête TCP (20 octets) - Surcharge WireGuard (32 octets)

Par exemple, pour une liaison réseau avec un MTU de 1500 octets, le MTU de l'interface WireGuard doit être défini comme suit :

IPv4 : 1500 (MTU de liaison) - 20 - 20 - 32 = 1428 octets

IPv6 : 1500 (MTU de liaison) - 40 - 20 - 32 = 1408 octets

Le paquet de données TCP Phantun résultant sera de 1500 octets, ce qui ne dépasse pas le MTU de l'interface de 1500.

Veuillez noter Phantun ne peut pas fonctionner correctement si la taille du paquet dépasse celle du MTU de la liaison, car Phantun n'effectue aucune fragmentation IP ni réassemblage. Pour la même raison, Phantun définit toujours le bit DF (Don't Fragment) dans l'en-tête IP pour empêcher les dispositifs intermédiaires d'effectuer une fragmentation sur le paquet.

Il est également fortement recommandé d'utiliser le même MTU d'interface pour les deux extrémités d'un tunnel WireGuard, sinon une perte de paquets inattendue peut se produire et ces problèmes sont généralement très difficiles à diagnostiquer.

Retour à la table des matières

Version compatibility

Bien que la pile TCP soit assez stable, l'attente générale est que vous exécutiez les mêmes versions mineures du serveur/client de Phantun aux deux extrémités pour garantir une compatibilité maximale.

Retour à la table des matières

Documentations

Pour les utilisateurs qui souhaitent utiliser la bibliothèque fake-tcp dans leur propre projet, reportez-vous à la documentation de la bibliothèque à l'adresse : https://docs.rs/fake-tcp.

Retour à la table des matières

Performance

Les performances ont été testées sur 2 instances AWS t4g.xlarge avec 4 vCPU et 5 Gb/s de NIC sur le réseau local. nftables a été utilisé pour rediriger le flux UDP de iperf3 à travers le tunnel Phantun/udp2raw entre les deux instances de test et le MTU a été ajusté pour éviter la fragmentation.

Phantun v0.3.2 et udp2raw_arm_asm_aes 20200818.0 ont été utilisés. Il s'agissait des dernières versions des deux projets en date d'avril 2022.

Commande de test : iperf3 -c <IP> -p <PORT> -R -u -l 1400 -b 1000m -t 30 -P 5

Article sur certaines des techniques utilisées dans Phantun pour obtenir ce résultat de performance : Writing Highly Efficient UDP Server in Rust.

Retour à la table des matières

Future plans

• Équilibrage de charge d'un seul flux UDP en plusieurs flux TCP
• Tests d'intégration
• Insertion/suppression automatique des règles de pare-feu nécessaires

Retour à la table des matières

Compariation to udp2raw

udp2raw est un autre projet populaire de @wangyu- qui est très similaire à ce que Phantun peut faire. En fait, j'ai pris les inspirations de Phantun à partir d'udp2raw. La plus grande raison de développer Phantun est le manque de performances lors de l'exécution d'udp2raw (en particulier sur les systèmes multi-cœurs comme le Raspberry Pi). Cependant, l'objectif n'est jamais d'être aussi complet en fonctionnalités qu'udp2raw et de ne prendre en charge que les cas d'utilisation les plus courants. Notamment, l'UDP sur ICMP et le mode UDP sur UDP ne sont pas pris en charge et il n'y a ni anti-rejeu ni chiffrement. L'avantage est une bien meilleure performance globale et moins de surcharge MTU en raison de l'absence d'en-têtes supplémentaires dans la charge utile TCP.

Voici un aperçu rapide de la comparaison entre les deux pour vous aider à choisir :

Retour à la table des matières

License

Copyright 2021-2025 Datong Sun ([email protected])

Sous licence Apache License, Version 2.0 <LICENSE-APACHE ou https://www.apache.org/licenses/LICENSE-2.0> ou la licence MIT <LICENSE-MIT ou https://opensource.org/licenses/MIT>, à votre discrétion. Les fichiers du projet ne peuvent pas être copiés, modifiés ou distribués sauf conformément à ces conditions.

Retour à la table des matières