VPN derrière un NAT que vous ne pouvez pas configurer : ce qui fonctionne encore

Chaque extrémité de tunnel a besoin d'une adresse et d'un port que l'autre côté peut joindre, et un routeur que vous n'administrez pas est la raison habituelle de l'échec de cette exigence. L'intéressant n'est pas que des astuces existent, mais que chacune dépende d'une propriété d'une table de mappage que vous ne voyez pas depuis le client. Deux de ces propriétés décident presque de tout : comment un mappage est créé, et s'il accepte des paquets venant d'une adresse que l'intérieur n'a jamais contactée. Classez l'environnement selon ces propriétés et les contournements cessent d'être du folklore.

La table de mappage décide de tout

La traduction d'adresses réseau tient une table où une adresse et un port internes sont enregistrés face à une adresse et un port publics. Les réponses qui correspondent à un enregistrement sont retraduites, et un paquet arrivant de l'extérieur sans enregistrement correspondant n'a aucune destination. Ce seul comportement explique pourquoi un écouteur derrière le routeur est injoignable depuis internet. Il explique aussi pourquoi le premier paquet dans chaque direction doit provenir de l'intérieur.

Regardez la table du côté du routeur et les contournements deviennent évidents : soit quelque chose crée une entrée permanente, soit quelque chose crée une entrée temporaire et la maintient fraîche, soit le trafic ne prend jamais ce chemin. Le reste de cet article est ces trois cas dans l'ordre. Rien ici ne dépend d'une fonction du fournisseur au-delà de ce que la table enregistre.

Ce que le service de rendez-vous peut et ne peut pas faire

Le perçage de trous UDP utilise l'enregistrement sortant comme une ouverture temporaire plutôt que de vaincre le filtre. Les deux pairs contactent un service de rendez-vous, qui apprend chaque extrémité publique et renvoie à l'autre côté sa propre extrémité. Ensuite les deux envoient l'un vers l'autre, et chaque paquet sortant crée ou rafraîchit l'enregistrement qui laisse entrer la réponse. L'ordre est ce qui le fait fonctionner, et l'ordre est aussi ce qui le rend fragile : un pair qui envoie avant que l'autre côté ait créé son enregistrement est simplement écarté, tandis qu'une nouvelle tentative un instant plus tard réussit. Le service lui-même ne transporte aucun trafic VPN, donc son seul levier est le minutage qu'il coordonne.

Le comportement du mappage décide du reste, et RFC 4787 nomme les trois formes : indépendant de l'extrémité, dépendant de l'adresse, et dépendant de l'adresse et du port. Avec la dernière, le port qu'un pair doit viser change à chaque destination, si bien que la prédiction cesse d'être fiable. C'est là que la technique rencontre ses impasses, car le NAT opérateur et un pare-feu d'entreprise strict suppriment tous deux la prévisibilité dont le schéma a besoin, et aucune quantité de tentatives ne la rétablit.

Keepalives, redémarrages et l'extrémité qui bouge

Un chemin percé est un flux et non un écouteur, donc tout ce qui tourne dessus doit survivre au changement. Il doit maintenir le mappage en vie par un trafic périodique, remarquer quand l'extrémité publique bouge, et se rétablir après le redémarrage du routeur ou la réattribution de l'adresse. Les produits de VPN maillé placent cette logique dans leur propre plan de contrôle, tandis qu'un serveur simple vous la laisse. Les keepalives n'aident que tant que le même mappage survit, et ils coûtent de la batterie sur un client mobile, c'est pourquoi un intervalle agressif n'est pas gratuit.

Un portable qui dort une heure revient généralement sur une autre extrémité publique. Tout ce qui rétablit le chemin doit s'exécuter de nouveau depuis l'intérieur, ce qui remet la même exigence sur le client.

Trois façons de contourner une redirection absente

La première façon demande au routeur de créer lui-même l'entrée, via UPnP IGD, NAT-PMP ou PCP, quand la fonction existe et est activée. La deuxième confie le trafic à un relais doté d'une adresse publique, ce qui fonctionne toujours et coûte toujours de la bande passante plus une frontière de confiance différente. La troisième inverse la direction : l'hôte interne ouvre un tunnel sortant vers un serveur public et tout le reste voyage à l'intérieur.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Une extrémité de relais rend cet échange visible dans la configuration du client, où l'extrémité est un relais et non l'adresse propre d'un pair. Le keepalive persistant maintient le mappage au chaud, et les préfixes autorisés décident de ce que le client peut envoyer à travers. Un tunnel inverse depuis l'hôte interne est la même idée avec un autre propriétaire, et elle n'exige aucun changement de NAT. Chacune des trois supprime l'exigence d'entrée sans vaincre un pare-feu qui bloque par conception le trafic non sollicité, car le trafic commence toujours à l'intérieur.

Adaptez le contournement à qui possède le routeur

Si vous administrez le routeur, une redirection UDP statique est plus simple à auditer que n'importe quel schéma de perçage et échoue d'une manière que vous voyez. Sinon, découvrez si le fournisseur propose un relais ou un plan de contrôle hébergé, et si la politique en autoriserait l'usage. Si aucun n'est disponible, les choix restants sont un tunnel inverse ou l'acceptation que l'extrémité n'est pas joignable depuis l'extérieur. Noter lequel vous avez utilisé compte plus qu'il n'y paraît, car les options diffèrent par qui peut observer le trafic et par ce qui se passe quand un tiers change quelque chose.

Notez si le chemin auquel vous avez abouti était direct ou relayé, car ce seul fait prédit à la fois la latence et le comportement en cas de panne. RFC 4787 reste la référence pour le comportement de mappage sous tout cela, et lire sa section sur le mappage est plus rapide que tester trois contournements à la suite. La table se moque de l'option que vous avez choisie ; elle enregistre seulement ce que le paquet suivant est autorisé à faire.