Pourquoi les clients OpenVPN manquent les sélecteurs IPsec de la passerelle

Pingez un hôte derrière le tunnel IPsec distant depuis la passerelle et il répond proprement, donc le tunnel semble sain et le ticket avance. Puis un client connecté essaie le même hôte et ne reçoit rien. Ce ping n’a jamais été une preuve pour le flux du client, car il est parti avec l’adresse source de la passerelle elle-même et a correspondu à un autre sélecteur IPsec. Comprendre pourquoi les deux cas divergent fait l’essentiel du correctif.

Le ping de la passerelle teste un flux que votre client n’utilise jamais

L’adresse source décide quelle politique s’applique. Un paquet généré sur la passerelle part avec une adresse de son LAN local ou de son extrémité de tunnel, et la politique qui y correspond a été écrite exactement pour ce cas. Le paquet d’un client arrive sur l’interface OpenVPN avec une adresse du pool de clients, ce qui est un sélecteur entièrement différent.

C’est pourquoi la panne ressemble à un problème de routage alors qu’il s’agit en réalité d’un problème de portée de politique. La joignabilité depuis la passerelle prouve que le pair est actif et que les propositions ont été négociées, et elle ne prouve rien sur la protection du pool.

Poussez le préfixe distant dont l’application a réellement besoin

Prenez la paire illustrative 10.8.0.0/24 pour les clients connectés et 172.30.239.0/25 pour le réseau distant protégé. Ce dont un client a besoin, c’est d’une route vers ce second préfixe, pas vers le LAN de la passerelle ni vers quelque autre adresse de tunnel. Une route poussée vers le pool est ce qui amène le client à remettre ce trafic à la passerelle. Sans elle, le paquet n’atteint jamais la décision de politique que vous déboguez.

Sur un serveur Community qui accepte les routes poussées, la directive reprend le vrai masque : push "route 172.30.239.0 255.255.255.128". Access Server configure la même destination via les réglages de réseau privé ou de règles d’accès de la version installée, avec le mode routé ou traduit choisi délibérément. Modifier les chaînes de pare-feu générées au lieu de la configuration propriétaire est la façon dont une installation qui fonctionne devient impossible à reproduire.

Après la connexion, lisez la table de routage du client plutôt que l’intention du serveur. Une route qui ne couvre que le pool signifie que la poussée n’est jamais arrivée, et une route par défaut via le tunnel est plus large que cette exigence et vous surprendra plus tard. Vérifiez le masque aussi bien que le préfixe, car un /25 poussé en /24 envoie le trafic des adresses voisines dans un chemin qui ne peut pas le porter. Confirmez ensuite que le client a choisi l’interface de tunnel pour cette destination.

Faites inclure le pool de clients dans les sélecteurs

Pour un accès routé qui préserve les adresses des clients, la politique IPsec doit protéger le trafic entre le pool et le préfixe distant. Les sélecteurs écrits pour le LAN propre de la passerelle admettent le ping et rejettent la requête du client, et c’est exactement l’asymétrie qui a lancé cette enquête.

Inspectez la politique négociée ainsi que les propositions configurées, par exemple avec ipsec statusall sur strongSwan ou la commande d’état équivalente de votre implémentation. Avec IPsec basé sur des politiques, la route ordinaire peut pointer vers une interface physique tandis que le trafic correspondant reste chiffré, donc l’absence de périphérique de tunnel ne prouve rien. Comparez les paires de sélecteurs au pool et au préfixe que vous avez notés.

Un NAT source générique sur la passerelle peut aussi casser la correspondance. Si une règle de masquerade réécrit la source du client avant la vérification de politique, le paquet ne ressemble plus au sélecteur que vous avez écrit. C’est une raison pour laquelle une règle de masquerade large est une mauvaise solution pour un second VPN : elle change la politique qui s’applique et l’adresse que le côté distant journalise. Exemptez le trafic que vous comptez router, ou traduisez-le délibérément et mettez les sélecteurs à jour.

Choisissez le routage ou la traduction à dessein

Le routage garde l’adresse du client visible pour le côté distant, donc les journaux distants et les règles par source restent significatifs, et il exige que la passerelle distante connaisse le chemin de retour vers le pool. La traduction cache le pool derrière une seule adresse, ce qui supprime le problème de route de retour et détruit l’identité par client.

Choisissez un seul design et écrivez-le, car les deux exigent des sélecteurs différents et un ordre de pare-feu différent. Un masquerade à moitié appliqué se place entre les deux et ne satisfait ni l’un ni l’autre. Le choix écrit est aussi ce qui permet à l’ingénieur suivant de distinguer un bug d’une décision délibérée.

Bouclez sur le transfert et la réponse

La passerelle doit transférer le protocole et la destination que vous voulez, ce qui suppose le transfert IP activé et une chaîne de transfert qui autorise la paire. Le côté distant doit ensuite renvoyer les réponses par le chemin IPsec, et c’est une décision de routage sur leur passerelle et non sur la vôtre. Les deux moitiés sont de la configuration ordinaire, et toutes deux restent facilement à moitié faites. Testez-les séparément pour qu’une règle de transfert manquante ne soit pas prise pour un tunnel cassé.

Vérifiez avec une vraie requête de client vers application, en la regardant traverser l’interface OpenVPN, la décision IPsec et l’hôte distant. Inspectez la réponse comme une observation séparée, car une requête qui arrive et une réponse qui ne revient jamais se ressemblent depuis la place du client. Une requête tracée vaut plus que n’importe quel nombre de pings depuis la passerelle.

Gardez l’autorisation de destination étroite pendant les tests, et confirmez qu’un client sans la règle ne peut pas atteindre le service. Une route installée plus une association établie n’est pas la même chose qu’un accès accordé.