Les clients VPN atteignent le serveur mais pas le réseau local : quelle solution ?

Le client ping l'adresse du tunnel du serveur OpenVPN et obtient une réponse, puis essaie un hôte du réseau local du serveur et n'obtient rien. Cette coupure circonscrit bien la panne : le tunnel est monté, le transfert fonctionne probablement, et la réponse sort par une porte qui ne ramène pas. Trois correctifs existent, et le bon dépend de ce que vous contrôlez et de ce que vous acceptez de perdre. Répondez aux trois questions ci-dessous dans l'ordre et le choix cesse d'être une affaire de goût.

D'abord, confirmer quel sens est cassé

La requête arrive sur l'interface tunnel avec une adresse source issue du pool VPN. Le serveur la transmet à l'hôte du réseau local, et cet hôte répond à la passerelle que sa propre table désigne, généralement le routeur local. Si le routeur n'a pas de route vers le pool, la réponse meurt là ou erre vers Internet.

Testez les deux machines avant d'en modifier une seule. Demandez au serveur quelle route sa table prendrait vers un client ; demandez à l'hôte du réseau local comment il joindrait la même adresse. La première recherche désigne généralement le tunnel et la seconde le routeur local, et cette différence est la panne en une ligne. Deux recherches coûtent moins cher qu'un audit de pare-feu et elles fixent le sens du problème.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Si l'hôte du réseau local pointe déjà vers le serveur VPN, votre problème est une règle de pare-feu ou une limite MTU, pas un chemin de retour manquant. N'ajoutez pas de route pour corriger un filtre.

Première question : pouvez-vous modifier le routeur du réseau distant ?

Quand le routeur local est à vous, une route statique vers le pool VPN avec l'adresse locale du serveur VPN comme prochain saut est la réponse propre. Elle préserve les adresses sources des clients, ce qui compte quand les hôtes locaux journalisent, filtrent ou limitent le débit par adresse. Elle ne demande aucune traduction sur le serveur, si bien que le tunnel reste un pur chemin de routage. L'obligation qu'elle crée est documentaire, car le pool, la route et la configuration du serveur doivent concorder.

Elle échoue silencieusement le jour où quelqu'un change le pool. Écrivez la valeur une fois et traitez toute modification dans l'un des trois endroits comme une modification des trois.

Un NAS ou un commutateur de couche 3 qui héberge le service a besoin de la même route, sauf s'il envoie tout via un routeur qui en dispose. Vérifiez l'équipement qui termine le sous-réseau, pas seulement celui tourné vers Internet. Les petits réseaux ont souvent trois appareils avec un avis sur le routage.

Deuxième question : le réseau local peut-il cesser de voir les adresses des clients ?

Quand le routeur appartient à quelqu'un d'autre, la traduction sur le serveur VPN ne demande aucune coopération. L'hôte local voit l'adresse locale du serveur, y répond, et le serveur retraduit en sens inverse. C'est pourquoi les appliances et les rôles d'accès distant fondés sur NAT se comportent ainsi.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Le coût, c'est l'attribution : les adresses par client disparaissent des journaux locaux. Toute liste d'autorisation sur l'hôte local doit alors nommer le serveur au lieu du pool.

Choisissez la traduction quand la coopération est indisponible, pas quand elle est simplement incommode. Elle cache le client à toute enquête future, y compris celles où vous devez savoir quel portable a ouvert une connexion. Elle peut aussi casser des protocoles qui intègrent des adresses dans la charge utile, car la traduction vit dans l'en-tête. Aucune des deux options n'est plus avancée ; elles répondent à des questions différentes sur la propriété.

Troisième question : le serveur est-il lui-même client d'un autre tunnel ?

Figurez-vous l'autre topologie : le serveur VPN compose aussi chez un fournisseur commercial, il a donc deux tunnels et deux jeux d'adresses. Le trafic qu'il transmet pour ses propres clients sort par le fournisseur, qui ne route pas les réponses vers les adresses du pool. C'est pourquoi les réponses disparaissent alors que les deux tunnels sont sains.

Le correctif consiste à masquer aussi le tunnel sortant, pour que le fournisseur ne voie que l'adresse tunnel du serveur. Le sens inverse exige sa propre règle, car le serveur qui ouvre une connexion vers l'un de ses propres clients est un flux différent. Sans cette règle, le client répond à une adresse qu'il ne peut pas router. Placez la règle étroite avant tout masquage large pour que la traduction spécifique l'emporte.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Les hôtes multiréseaux ajoutent une panne connexe qui paraît identique depuis le client. La réponse sort par l'interface de métrique la plus basse parce que l'adresse source a été choisie dans une autre table. Vérifiez le chemin de retour par une recherche au lieu de supposer que le chemin aller l'implique.

Vérifiez ensuite les deux sens et les deux tailles

Après la modification, pingez du client vers un hôte local, puis de l'hôte local vers le client. Le second sens est celui que l'on saute, et c'est celui qui révèle une règle de traduction incomplète. Notez les deux résultats avec leur horodatage pour qu'une régression ultérieure soit comparable.

Déplacez ensuite de vraies données, car un petit ping qui réussit alors qu'un gros transfert cale est un symptôme MTU. Cette panne apparaît juste après que vous vous êtes félicité d'avoir corrigé la route.

Enfin, retestez après un redémarrage. Les commandes de route et de pare-feu à chaud n'y survivent pas, et un correctif qui disparaît au redémarrage suivant sera diagnostiqué de nouveau par quelqu'un qui a moins de contexte. Rendez la modification persistante comme votre système le fait déjà, puis redémarrez une fois exprès.