Présentation
gonc est un outil netcat écrit en Go qui cible les communications point‑à‑point (P2P) entre deux hôtes séparés par des routeurs NAT. Le programme se décline en ligne de commande et en interface graphique (gonc‑gui) pour Windows et Android, mais conserve la même logique d’échange de passphrase. La syntaxe reste compatible avec nc :
gonc www.example.com 80Mécanisme de traversée NAT
Le paramètre -p2p active une découverte automatisée d’adresses publiques via les services publics STUN et MQTT. Chaque côté envoie sa passphrase à un broker MQTT ; le broker relaie les adresses IP/port détectées par le client STUN, permettant ainsi le « hole punching ». Le processus fonctionne tant en IPv4 qu’en IPv6, mais l’exemple fourni force IPv4 avec -4 pour illustrer la traversée d’un NAT « hard » (symétrique) contre un NAT « easy ». La durée maximale d’attente avant abandon est d’environ trente secondes, après quoi le client peut invoquer -mqtt-wait et -mqtt-hello pour synchroniser explicitement les deux parties.
Chiffrement et authentification
gonc utilise TLS 1.3 pour le trafic TCP et DTLS pour le trafic UDP. La passphrase sert à dériver les certificats mutuels, garantissant une authentification bidirectionnelle sans échange de clés pré‑partagées supplémentaires. Le mode -tls ou -dtls chiffre chaque octet transmis, et le protocole négocie automatiquement le rôle client/serveur. Cette architecture élimine le besoin d’un PKI externe ; la sécurité repose uniquement sur la force de la passphrase (générée avec -psk pour une entropie élevée).
Fonctionnalités avancées et limites
Outre le transfert de fichiers (-httpserver ou -download), gonc propose des services virtuels : SOCKS5, proxy HTTP, exécution de commandes via -exec ou -pty, et mesure de bande passante avec -send /dev/zero. Le mode -link encode l’adresse distante dans un sous‑domaine (10.0.0.1-3389.gonc.cc) qui se résout en 127.b.c.d, simplifiant l’accès à des services internes via un client RDP. Le -nat-checker affiche les adresses NAT détectées et leur classification : « (easy) », « (hard) » ou « (symm) », ce qui indique la probabilité de succès du hole punching. Cependant, le système dépend de la disponibilité des serveurs STUN/MQTT publics ; une interruption ou un filtrage de ces services empêche la découverte automatique. De plus, les NAT symétriques restent les plus difficiles à traverser et exigent que l’autre extrémité possède au moins un NAT « easy » ou « hard ». Enfin, la couche TLS ne protège pas les métadonnées de connexion (adresse IP, port) qui restent visibles pour un observateur réseau.
