Deux adresses de service sur un seul client OpenVPN : iroute et lo

L’application répond sur son adresse de tunnel, et l’adresse que vous avez documentée pour elle ne mène nulle part. Rien dans le journal OpenVPN ne se plaint, le pair apparaît connecté et le concentrateur ne liste qu’un seul client. Le vide vient de ce qu’une seconde adresse sur un client est deux faits distincts : l’hôte doit la posséder, et le concentrateur doit savoir quel pair la possède. Traitez l’un sans l’autre et le trafic meurt au concentrateur ou arrive sans route de retour.

L’alias est local, la propriété est distante

Une adresse de tunnel se négocie, donc les deux extrémités l’apprennent pendant la poignée de main. Une adresse de service supplémentaire ne se négocie pas du tout, ce qui explique que l’ajouter ne change rien au concentrateur en soi. Le client peut posséder l’adresse immédiatement et le serveur enverra quand même ce trafic sur son chemin par défaut ou le rejettera. Deux enregistrements doivent être créés, à deux endroits différents.

Sur le client, l’adresse appartient à l’hôte, et loopback est le foyer naturel d’une identité de service qui ne devrait jamais apparaître sur un lien physique. Sur le concentrateur, la correspondance pair-préfixe est une déclaration séparée que seul le serveur lit. Aucun des deux enregistrements n’implique l’autre.

Gardez les deux plages distinctes dans vos notes aussi. Les adresses d’un exemple sont des valeurs de documentation, et les chevaucher avec un LAN réel est le moyen le plus rapide de faire paraître cassée une configuration qui fonctionne.

Ajoutez l’adresse sur le client de façon persistante

Placez l’adresse de service sur loopback avec un préfixe d’hôte, pour que l’hôte la traite comme une entrée locale et non comme un sous-réseau à atteindre. ip address add 10.66.0.10/32 dev lo le fait pour une adresse, et répéter la commande pour une seconde adresse modélise deux services.

Exécutez cela comme un test ponctuel, puis déplacez-le dans ce qui possède la configuration réseau de l’hôte, car un ajout à l’exécution disparaît au redémarrage et les doublons s’accumulent entre les reconnexions. Une unité systemd ordonnée après le réseau est une option, et un gestionnaire de réseau de distribution en est une autre. Quel que soit votre choix, l’adresse doit exister avant que l’application ne se lie, sinon le service démarre sur la mauvaise socket. Vérifiez avec ip address show dev lo après un redémarrage plutôt qu’après la commande manuelle.

La liaison est une décision distincte de l’adressage. Une application qui écoute sur toutes les adresses accepte du trafic sur des interfaces que vous n’avez jamais prévues, alors pointez-la vers l’adresse de service précise. La politique d’entrée locale a alors quelque chose de précis à comparer.

Revendiquez-la dans le fichier CCD que le concentrateur lit vraiment

Sur le serveur, la déclaration de propriété va dans le fichier par client sélectionné par le nom commun authentifié, à l’intérieur du répertoire nommé par client-config-dir. La ligne est iroute 10.66.0.10 255.255.255.255, une par adresse, et elle indique au serveur quel pair doit recevoir le trafic pour cette destination.

Deux détails cassent cela en silence. Le nom de fichier doit correspondre au nom que le serveur utilise réellement, qui diffère lorsque username-as-common-name est en jeu. Et iroute ne prend effet qu’en mode TUN avec un répertoire de configuration client configuré, donc la même ligne ne fait rien dans un déploiement en pont. Ajoutez des lignes au fichier existant plutôt que de le remplacer, car il peut déjà porter une adresse fixe ou des options push. La référence OpenVPN 2.6 documente le répertoire et la directive de propriété.

Le noyau du concentrateur lui-même a aussi besoin d’un chemin vers ces destinations pour que le trafic généré localement entre dans le processus de tunnel. route 10.66.0.10 255.255.255.255 dans la configuration du serveur couvre le trafic que le serveur origine, tandis que les autres clients ont besoin de push "route 10.66.0.10 255.255.255.255" pour apprendre la destination eux-mêmes.

Le routage et l’autorisation restent séparés. Une route poussée indique à un client où envoyer les paquets et n’accorde rien ; le service doit encore accepter l’appelant selon ses propres conditions.

Vérifiez la politique d’entrée et le chemin de retour

Un paquet adressé à l’alias arrive sur l’hôte propriétaire comme entrée locale, donc la question est de savoir si le pare-feu local autorise cette source et ce port. Autorisez le port de service précis depuis la plage de sources VPN au lieu d’ouvrir toute l’adresse.

Les réponses ont besoin d’un chemin de retour vers l’appelant. Pour un appelant dans le pool de tunnel normal, ce chemin existe déjà, car l’appareil de tunnel le transporte. Un appelant derrière un autre réseau routé a aussi besoin de la route de retour de ce réseau, et c’est là que les configurations asymétriques perdent des paquets.

Surveillez un second écouteur sur le même port lié à une adresse différente, car le noyau livre à la socket qui correspond et les résultats semblent aléatoires. Vérifiez avec ss -lntp et confirmez que l’adresse liée est l’alias du service. Le NAT source n’est pas nécessaire ici, et l’ajouter masque l’identité de l’appelant dont vos journaux dépendent.

Testez les adresses et la propriété séparément

Testez en deux étapes. Confirmez d’abord que l’hôte propriétaire peut atteindre le service sur son alias depuis lui-même, ce qui sépare les problèmes de liaison et de pare-feu du routage. Testez ensuite depuis un appelant VPN réel en utilisant l’authentification de l’application elle-même. Quand le premier passe et que le second échoue, la pièce manquante est du côté du concentrateur.

Vérifiez aussi les modes de défaillance qui survivent à une connexion : l’alias reste attribué quand le tunnel est arrêté, et le concentrateur garde sa route quand le pair est absent. Aucun objet seul ne prouve que le service est joignable, et c’est pourquoi le test en deux étapes bat un simple ping depuis un portable.