Ouvrir le port VPN ne fait pas accéder les clients au LAN

Le tunnel monte, le client s’authentifie, mais le LAN derrière la passerelle reste invisible. La règle censée corriger cela autorise le port VPN et fonctionne exactement comme écrit, car elle régit les paquets adressés à la passerelle elle-même. Le trafic du client vers un hôte derrière la passerelle a une autre destination et une autre chaîne. Une connexion réussie ne change pas laquelle des deux chaînes le noyau consulte.

Deux chaînes, deux destinations différentes

Le sort d’un paquet se décide par là où il va, pas par la façon dont il est arrivé. Le trafic adressé à une adresse de la passerelle est remis localement et évalué par les règles d’entrée. Le trafic que la passerelle transfère est évalué par les règles de transfert. La même interface de tunnel peut produire les deux types de paquets, c’est pourquoi une seule règle ne peut pas couvrir les deux tâches.

Tout le mythe en une phrase : autoriser l’écouteur ne dit rien sur l’autorisation du réseau qui se trouve derrière. Ce sont deux décisions distinctes avec des preuves distinctes, et un nom d’interface sur les deux ne les fusionne pas.

Ce que la règle de l’écouteur autorise réellement

Les paquets de l’écouteur se terminent dans le processus VPN, et c’est ce qui permet d’établir le tunnel. La page d’administration de la passerelle et une réponse de diagnostic locale utilisent aussi le chemin d’entrée de l’hôte, c’est pourquoi un test vers la passerelle réussit alors que tout ce qui est derrière échoue. Les deux résultats sont corrects et aucun ne concerne le LAN.

Quand le processus décapsule le trafic du client pour une autre destination, le paquet entre dans le chemin de transfert et y a besoin d’une autorisation. L’authentification réussie règle qui est le client ; elle ne règle pas où il peut aller. Les deux questions ont des propriétaires, des journaux et des messages d’erreur différents.

Testez depuis un client, jamais depuis la passerelle

Un test généré sur la passerelle suit le chemin de sortie de l’hôte et peut réussir alors que le chemin transféré est fermé. Lancez le test depuis le client et observez les deux extrémités du flux.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Si la requête apparaît sur tun0 et que rien n’atteint la destination, le paquet est abandonné après son arrivée, ce qui indique les règles de transfert ou le filtrage propre à la destination. Si rien n’apparaît du tout sur tun0, le client ne l’envoie même pas au tunnel, et le problème est le routage sur le client et non la politique sur la passerelle. Comparez avec une requête qui sort correctement et ne revient pas, ce qui est le cas du chemin de retour.

Le transfert exige trois choses, pas une

Le transfert du noyau doit être activé, une règle de filtre doit accepter le flux, et la destination doit être joignable avec un chemin pour le retour de la réponse. Si l’une des trois manque, le silence est identique du point de vue du client.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Lisez les trois sorties ensemble. Un zéro dans la première rend les deux autres inutiles, et une politique de rejet par défaut dans la seconde rejette les paquets du client tandis que le trafic propre de la passerelle continue de fonctionner. La troisième sortie montre pourquoi la règle de l’écouteur n’a jamais été le problème.

Gardez les deux jeux de règles séparés dans la documentation

Écrivez la règle de l’écouteur et celle du service transféré sur des lignes distinctes, avec des propriétaires et des raisons distincts. Quand le port VPN change ou qu’un nouveau service est publié, cette séparation empêche un changement d’élargir silencieusement l’autre.

Plutôt que de traiter chaque pair authentifié comme un membre de confiance du LAN, utilisez des règles étroites pour les plages de clients et les services qui en ont besoin. Les notes de transfert de StrongSwan décrivent le côté route de retour et traduction de la même frontière, ce qui est encore une troisième décision.

Enfin, gardez les couches droites quand un utilisateur est refusé. Si la requête atteint l’hôte et que l’application refuse le compte, réparez l’autorisation de l’application à cette couche ; élargir le transfert ne peut pas fournir un identifiant de partage de fichiers et élargira l’accès pour tous les autres qui se connectent correctement.