Le même sous-réseau aux deux extrémités : mappez le LAN distant sur une plage libre

La maison et le bureau utilisent tous deux 192.168.1.0/24, donc une requête vers 192.168.1.1 a deux réponses possibles et le client en choisit une sans demander. Renuméroter un réseau de bureau en production est rarement populaire, et les adresses du routeur sont souvent gravées dans les imprimantes, les caméras et la documentation. Un mappage d'adresses côté client peut au contraire présenter le réseau distant sous une plage libre, et la partie hôte peut rester identique pour que 192.168.1.20 apparaisse comme 10.203.41.20. Le piège est que seuls certains clients l'implémentent, et qu'il ne fait rien pour le chemin de retour.

Deux vues du même hôte

Le mappage conserve la partie hôte et ne change que la partie réseau. La même machine répond alors à deux adresses selon l'endroit où vous vous trouvez. Noter les deux colonnes avant de configurer quoi que ce soit évite une mauvaise lecture ultérieure des journaux et des règles du pare-feu.

Les appareils locaux à la maison conservent leurs propres adresses 192.168.1.x, et c'est tout l'intérêt de l'exercice. L'imprimante de la pièce voisine reste joignable tandis que le bureau apparaît sous une plage qui n'entre pas en collision.

L'ordre des arguments est toute l'astuce

L'option prend une direction, un réseau et un masque, et un alias : le premier réseau est ce que voit le client, l'alias est ce que voit le serveur. Pour les ressources qui vivent derrière la passerelle distante, la direction est la forme de destination. Inverser les deux réseaux parce que le dernier argument s'appelle un alias est l'erreur qui produit un tunnel qui se connecte et ne mappe rien.

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

La route est ce qui envoie les paquets du client pour la nouvelle plage dans le tunnel ; la traduction réécrit la destination au passage. Une réponse de 192.168.1.20 est réécrite vers 10.203.41.20 pour que le socket du client reste cohérent. Un seul hôte fonctionne de la même façon avec un masque de longueur complète, tant que la route et le mappage décrivent la même adresse.

Il s'agit d'un mappage d'adresses, pas d'un mappage de ports. Deux services sur un même hôte ne peuvent pas être séparés avec lui, et un protocole qui intègre des adresses IP dans sa charge utile verra toujours les vraies.

Le mappage ne crée pas de chemin de retour

La traduction se fait chez le client, donc le serveur doit toujours router les réponses vers le tunnel et son pare-feu doit toujours les autoriser. Si la passerelle distante ne sait pas comment atteindre le sous-réseau du tunnel, la requête arrive et la réponse sort par la mauvaise porte ; le mappage ne fait que faire ressembler la panne à un problème de client.

Les règles côté serveur devraient décrire les adresses qui existent sur le serveur après la traduction, pas la plage visible par le client. Copier l'alias dans une règle d'autorisation gâche un après-midi, car aucun paquet de ce côté ne le porte.

Choisissez une plage d'alias qui n'entre en collision avec rien d'autre que le client route : un autre VPN, un réseau de conteneurs, un second bureau. Une collision ici réintroduit l'ambiguïté d'origine sous un autre numéro et est plus difficile à voir parce que les adresses semblent inconnues.

Les noms et les charges utiles survivent à la traduction

Un nom d'hôte qui se résout vers la vraie 192.168.1.20 envoie le navigateur vers l'appareil local plutôt que vers le distant, quoi que dise la table de routage. La réponse du DNS privé doit pointer vers la plage visible par le client, tandis que le certificat TLS porte toujours le nom que l'application attend. Testez avec le nom plutôt qu'avec l'adresse, car l'adresse peut fonctionner pendant que le nom se résout silencieusement dans la mauvaise direction. Lorsque la passerelle distante sert aussi cette zone, ses propres enregistrements ont aussi besoin de la plage visible par le client.

Les redirections, les URL intégrées et les applications qui livrent leur propre adresse dans une charge utile peuvent casser de manières qu'aucun mappage de paquets ne peut réparer. Traitez-les comme un problème d'application et dimensionnez l'effort en conséquence avant de promettre que la renumérotation est inutile.

Trois vérifications avant de vous engager

Premièrement, confirmez l'implémentation du client. Community OpenVPN prend en charge cette option ; la base de code d'OpenVPN 3 la classe parmi les fonctionnalités non prises en charge, donc un profil poussé vers un client de style Connect peut simplement l'ignorer. Une directive acceptée et jamais appliquée est pire qu'une erreur, car le tunnel semble sain.

Deuxièmement, vérifiez la route et la traduction séparément avec une courte fenêtre de diagnostic à verbosité élevée, puis testez le service réel plutôt qu'un ping. Troisièmement, confirmez que le routeur local et la ressource distante restent distinguables depuis le client, car c'était l'objectif initial.

Si le client ne peut pas faire la traduction, demandez de l'aide du côté de la passerelle ou acceptez une renumérotation. Ajouter davantage de routes pour la même adresse n'est pas une conception.