NAT sur le serveur VPN ou sur le routeur ? Les deux peuvent fonctionner

Marquer une connexion comme route par défaut sur un ordinateur portable est l’étape dont tout le monde se souvient, et c’est celle qui ne change rien sur la passerelle. Le client envoie désormais les requêtes Internet dans le tunnel ; leur sortie du bâtiment dépend du transfert, d’un point de traduction et d’un chemin de retour qui atteint l’adresse privée du client. Deux dispositions peuvent fournir les trois, elles placent le travail à des endroits différents, et toutes deux échouent de la même manière silencieuse quand personne n’assume la direction de la réponse. Choisir entre elles est une question de qui doit voir le pool de clients.

Le mythe : une route client construit la sortie

Le tunneling forcé est une politique côté client : il décide que le trafic passe par l’adaptateur VPN plutôt que par l’adaptateur physique. La documentation de Microsoft sur le routage VPN décrit ce fractionnement et ce comportement forcé, et c’est une affirmation sur la table de routage du client, non sur les règles de transfert du serveur. Du point de vue du client, le tunnel est là où vit Internet ; du point de vue de la passerelle, un paquet est arrivé d’une adresse dont personne en amont n’a jamais entendu parler. Aucun des deux côtés n’est mal configuré isolément, et c’est pourquoi la panne ressemble à un serveur en panne pour la personne devant l’ordinateur portable.

Cette inadéquation est tout le problème que règle le reste de cet article. Quelque chose doit rendre l’adresse privée du client joignable en retour, et le choix porte sur l’endroit.

Dessinez d’abord le chemin de retour

Écrivez le chemin avec de vraies adresses avant de toucher à un réglage, et marquez-y les deux points de traduction candidats. Ce laboratoire utilise un pool VPN de 10.70.0.0/24 avec un client à 10.70.0.37, une adresse LAN du serveur de 172.16.40.10, un routeur à 172.16.40.1 et une sortie publique de 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

Le serveur qui navigue déjà sur Internet ne prouve que son propre chemin. Un paquet transféré au nom d’un client est une décision différente, prise par la politique de transfert sur la même machine, et c’est celle qui manque habituellement. Marquer les trois points de décision sur le schéma maintient la conversation sur un seul d’entre eux à la fois.

Option A : traduire sur le serveur VPN

Ici, le serveur traduit la source du client vers sa propre adresse LAN avant de remettre le paquet au routeur, et le routeur applique sa traduction ordinaire à la sortie. Sur la réponse, la correspondance du routeur restaure l’adresse du serveur et celle du serveur restaure l’adresse du client. Deux traductions à état en série sont normales et praticables, à condition que les deux soient enregistrées ; le routeur n’a jamais besoin d’une route vers le pool, et c’est l’attrait de cette disposition.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Utilisez ces lectures pour voir ce que le serveur possède déjà plutôt que de supposer qu’un NAT est en place. Une règle de masquerade Linux copiée d’un blog n’est pas une configuration Windows, et une autorisation dans le pare-feu de l’hôte pour l’écouteur VPN n’est pas la même politique que l’autorisation de transférer la requête d’un client plus loin. Confirmez le rôle de transfert du serveur depuis sa propre surface d’administration, puis examinez la traduction séparément, car les deux sont souvent activés par des parties différentes d’un déploiement.

Option B : porter le pool jusqu’au routeur

Dans la seconde disposition, le serveur transfère la véritable adresse source du client, et le routeur la traduit. Cela garde le pool de clients visible en périphérie, ce qui aide si le routeur est l’endroit où vivent la politique de trafic, la journalisation ou l’inspection. Cela signifie aussi que le routeur a besoin d’une route de retour pour 10.70.0.0/24 pointant vers 172.16.40.10, plus une politique Internet qui inclut réellement ce préfixe ; une règle écrite pour le sous-réseau LAN ne s’étend pas silencieusement au pool.

Choisissez ceci quand l’équipement de périphérie est le propriétaire prévu de la politique et peut accepter un autre préfixe dans ses tables de routage et de traduction. Choisissez la traduction côté serveur quand le pool doit rester invisible en amont et que le routeur n’est pas administré par la même équipe. Aucune des deux options n’est induite par une case à cocher sur le client, et aucune n’est plus sûre en général ; elles placent la visibilité et la maintenance à des endroits différents.

Rendez explicites le DNS, l’IPv6 et l’acceptation

La traduction d’adresses ne règle pas la résolution de noms. Le client peut utiliser un résolveur fourni avec le profil VPN, un résolveur privé pour certains espaces de noms, ou un résolveur public approuvé, et un résolveur injoignable sous cette politique continuera d’échouer une fois le routage opérationnel. Testez un nom et une adresse séparément afin que les deux pannes ne fusionnent jamais dans un seul rapport.

L’IPv6 a besoin de son propre paragraphe dans la conception. Une traduction IPv4 qui fonctionne ne dit rien sur le fait que les clients IPv6 aient une route, une source publique valide ou une politique qui les bloque lorsque le tunnel tombe. Laisser cela non dit signifie que la moitié des clients contournent la passerelle en silence pendant que l’autre moitié fonctionne.

Pour l’acceptation, suivez une requête client autorisée et sa réponse à travers les deux frontières, et notez l’adresse que chaque frontière devrait voir à ce moment. C’est cet enregistrement qui fait du prochain changement de pool une modification de cinq minutes plutôt qu’une discussion sur qui possède la route de retour manquante. Conservez l’enregistrement avec le profil du client plutôt que dans un ticket, car le profil est ce que le prochain ingénieur trouvera en premier.