pfSense en serveur et client VPN : deux chemins, un seul routeur

Un seul équipement peut regarder dans deux directions à la fois: les utilisateurs nomades se connectent vers l’intérieur, et la même boîte se connecte vers l’extérieur à un fournisseur de sortie pour que le trafic sélectionné quitte par un autre réseau. Activer les deux services prend quelques minutes ; les faire coexister demande une conception, car le second rôle réécrit la table de routage dont le premier dépend. Trois conditions décident si le montage fonctionne, à savoir si le service entrant conserve sa propre route de retour, si le tunnel sortant atteint encore son pair et si le trafic que vous vouliez transmettre est sélectionné pour la sortie. Trompez-vous sur une et vous obtenez deux tunnels qui annoncent tous deux connecté alors que rien d’utile ne passe entre eux. Les vérifications ci-dessous établissent chaque condition dans l’ordre où les pannes apparaissent d’habitude.

Nommez les deux rôles avant de toucher à un réglage

Notez quatre faits par instance : son pair distant, son matériel d’authentification, le pool d’adresses qu’elle distribue et les réseaux derrière elle. Les deux instances sont des objets distincts sur l’équipement et doivent le rester dans vos notes aussi. Presque chaque symptôme déroutant vient ensuite du mélange de leurs valeurs, et deux instances qui partagent un seul jeu de notes, c’est ainsi que le mauvais pool finit dans le mauvais champ.

Le service entrant a besoin d’un réseau de tunnel qui ne chevauche ni les adresses du tunnel sortant ni aucun réseau privé que l’équipement route. Le chevauchement est la seule erreur qui produit des symptômes dans les deux rôles à la fois, et il est bien moins coûteux de l’attraper sur le papier. Comparez les deux pools et chaque réseau privé routé au même endroit avant de configurer l’un ou l’autre service.

Du matériel partagé n’implique pas des identifiants partagés, et un certificat client issu du pool d’accès distant ne devrait pas être utilisable contre le fournisseur de sortie. Un matériel séparé transforme aussi la révocation en décision locale plutôt qu’en événement pour toute la flotte.

Gardez les réponses du serveur sur le chemin WAN

Les réponses que l’équipement génère lui-même sont la première victime d’une route par défaut négligée. Quand le paquet encapsulé d’un utilisateur nomade arrive, la réponse est du trafic d’origine locale et doit sortir par l’interface par laquelle cet utilisateur est entré. Si le client sortant a installé une route par défaut qui la capture, la réponse entre dans le mauvais tunnel et la session bloque alors que le service paraît encore sain.

Aucune case à cocher ne règle cela, car la décision porte sur le trafic que le client sortant peut capturer. Soit vous ne tirez aucune route et ne dirigez que ce que vous sélectionnez, soit vous tirez des routes et ajoutez les exceptions qui maintiennent les services propres de l’équipement. Écrivez le choix à côté de l’instance, sinon la personne suivante supposera l’autre.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Lisez la table de routage par la correspondance la plus longue et non par l’ordre dans lequel vous avez configuré quoi que ce soit. La question est quelle entrée gagne pour l’adresse du pair de sortie et quelle entrée gagne pour la réponse du service entrant, et ces deux réponses peuvent différer.

Ne laissez pas le tunnel sortant manger son propre point de terminaison

Le client sortant doit atteindre l’adresse publique de son pair pour établir le tunnel, ne serait-ce que. Si cette adresse est elle-même routée dans le tunnel, le client se poursuit la queue : le transport ne monte jamais, ou il monte puis tombe à l’instant où la route s’installe. Le journal ressemble à un délai d’authentification dépassé plutôt qu’à une panne de routage, et c’est pourquoi la route mérite la première vérification.

Vérifiez la route avant les identifiants et de nouveau une fois le tunnel monté, car une entrée peut être correcte au démarrage et fausse une minute plus tard. L’adresse du pair doit pointer vers le chemin WAN ordinaire, jamais vers le périphérique de tunnel. Une fois le transport stable, la question intéressante passe au trafic transmis, qui est la décision suivante.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Choisissez quels utilisateurs obtiennent la sortie

La politique de source appartient à l’entrée où le trafic entre dans l’équipement, donc choisissez le pool d’accès distant, ou des identités plus étroites à l’intérieur. Préservez les destinations privées et les exceptions de gestion qui ne doivent jamais partir vers la sortie, et placez ces règles avant la règle large. Le chemin de sortie a alors besoin de sa propre traduction ou d’un montage de retour routé, ce qui, pour la plupart des conceptions, signifie du NAT sortant sur l’interface de sortie couvrant le pool. La traduction ne choisit pas une sortie ; elle ne réécrit que ce qui est déjà parti, donc une règle NAT sur un WAN sans rapport ne change rien à la sélection.

Confirmez que l’extrémité distante autorise le trafic transmis de cette conception, car certains fournisseurs le font et d’autres non. La différence se voit comme un tunnel qui se connecte et ne transporte rien, ce qui se lit facilement comme une panne locale. Testez les trois flux séparément, car ils échouent indépendamment et deux sur trois, c’est une conception à moitié construite.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

La première commande est la connexion extérieure de l’utilisateur nomade, et elle fonctionne quand le client signale que la séquence d’initialisation est terminée. La deuxième, lancée depuis cet ordinateur portable connecté, devrait signaler l’adresse du fournisseur de sortie plutôt que votre adresse WAN. La troisième s’exécute sur l’équipement liée à une adresse du pool, et elle teste la politique de source pour le trafic transmis sans impliquer du tout un utilisateur distant. Si elle répond depuis le WAN à la place, la politique n’a pas correspondu, et aucune retouche de NAT ne corrige un problème de sélection.

Décidez ce qui se passe quand la sortie tombe

Écrivez le comportement en cas de panne avant qu’elle n’arrive : quand le tunnel sortant tombe, les utilisateurs reviennent-ils au WAN ordinaire ou sont-ils bloqués jusqu’au retour de la sortie ? Les deux réponses sont défendables, et l’équipement ne choisira pas pour vous. Une route supprimée ou une politique pointant vers une passerelle morte ne produit pas automatiquement un résultat entièrement bloqué. Si vous voulez le blocage, la politique doit le dire explicitement, et il faut le tester en retirant la sortie plutôt qu’en raisonnant dessus. Si vous voulez le repli, publiez-le auprès des utilisateurs, car le trafic qui prend silencieusement le chemin ordinaire est exactement celui que quelqu’un croyait couvert.

Désactivez l’instance cliente, regardez ce qu’un utilisateur connecté peut encore atteindre, puis redémarrez-la. Une requête qui expire est le résultat entièrement bloqué que vous avez demandé ; celle qui répond avec l’adresse WAN est le repli que vous n’avez pas documenté. Répétez la vérification pour IPv6 et pour DNS, car une politique écrite pour IPv4 ne dit rien du trafic AAAA et un résolveur poussé par l’un ou l’autre tunnel répond d’où la requête sort réellement.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

La recette Netgate pour OpenVPN routé montre comment la politique de source, l’affectation d’interface et la traduction sortante s’articulent, et sa portée de site à site est la partie à ne pas copier intégralement. Ce qu’elle ne vous dira pas, c’est laquelle des trois conditions ci-dessus votre propre conception a déjà cassée.