Pourquoi un VPN qui fonctionne expire quand même sur la réponse
Qu'une requête atteigne un serveur privé ne représente que la moitié de l'échange. Sa réponse doit retrouver le client du tunnel par la passerelle, la route ou la traduction prévues.
La requête arrive, le serveur la journalise, et le client signale toujours un délai d'attente dépassé. Cette combinaison signifie que la réponse n'a pas retrouvé son chemin de retour, et c'est l'une des rares pannes que vous pouvez confirmer des deux côtés à la fois. Faites les vérifications dans l'ordre et arrêtez-vous dès que l'une échoue.
Commencez par l'endroit où la requête est arrivée
Confirmez que le paquet a atteint le service avant d'inspecter quoi que ce soit d'autre. Une entrée de journal côté serveur, un compteur de connexions ou une capture autorisée à l'extrémité distante répondent tous à la même question, et leur absence vous renvoie vers le tunnel plutôt que vers la réponse. C'est la vérification qui sépare un problème de transfert d'un problème de chemin de retour.
Si la requête n'est jamais arrivée, arrêtez-vous ici. Le tunnel, le routage vers le préfixe privé ou la règle d'accès sont le sujet, et le chemin de la réponse n'est pas encore pertinent. Notez aussi l'adresse source que le serveur a vue. C'est soit l'adresse du pool attribuée au client, soit une adresse traduite, et cette différence détermine laquelle des vérifications suivantes s'applique.
La réponse a besoin d'une route vers le pool
Un client d'accès distant reçoit généralement une adresse d'un pool, et le réseau privé a besoin d'une route de retour vers ce pool. Un serveur dont la route par défaut pointe vers sa propre passerelle remet le paquet à cette passerelle, qui n'a aucune idée de l'endroit où vit le pool, et la réponse meurt là. Le client voit un délai d'attente parce que rien n'est revenu, ce qui est indiscernable d'une requête qui n'est jamais partie.
Vérifiez la route que le serveur choisit pour l'adresse du client, et non celle qu'il utilise pour son propre sous-réseau. Ces deux recherches peuvent donner des réponses différentes, et c'est la seconde qui compte ici. La traduction est la conception alternative et elle change ce que le serveur voit. Elle peut simplifier un chemin de retour, et elle retire aussi l'adresse d'origine du client des journaux du serveur, ce qui affecte toute règle ou tout rapport construit sur ce champ.
Comparez la capture du serveur avec la capture de la passerelle
Comparez ce qui quitte le serveur avec ce qui arrive à la passerelle. Une capture sur l'interface sortante du serveur et une capture sur la passerelle du tunnel répondent à deux moitiés différentes de la question, et l'écart entre elles localise la perte.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
Une requête générée par la passerelle elle-même est un piètre substitut à un test depuis le client, car elle provient d'une autre adresse et rencontre d'autres règles. C'est pourquoi un ping réussi depuis la passerelle et une requête en échec depuis le client peuvent être vrais tous les deux.
Quand plusieurs routeurs se trouvent sur le chemin, vérifiez chacun de ceux qui ont besoin d'une route vers le pool. Une conception site à site exige souvent que le préfixe distant soit connu sur plus d'un équipement, et la passerelle elle-même doit transférer entre le tunnel et le LAN ; les notes de transfert de strongSwan couvrent le côté sysctl et pare-feu de la chose.
Notez le pool, le préfixe et le responsable
Quatre faits appartiennent à la note : le pool reçu par le client, le préfixe privé dont il avait besoin, le routeur responsable de la réponse et la règle de traduction si elle existe. Avec eux, un changement de passerelle ultérieur devient une comparaison et non une enquête.
Retestez ensuite avec un client ordinaire et le vrai compte de l'application. Élargir les privilèges de l'application ne peut pas réparer le chemin de retour d'un paquet, et une modification de compte faite pendant ce diagnostic brouillera la comparaison suivante. Si la conception repose sur la traduction, documentez-la là où les journaux du serveur sont lus. La personne qui voit une adresse source inconnue dans une piste d'audit ne devrait pas avoir à redécouvrir la correspondance depuis un ticket.