La passerelle héberge sa propre page d'administration : adresse interne ou publique

Une page d'administration répond depuis un téléphone en données mobiles et expire depuis un ordinateur portable joint au VPN. Rien n'est cassé dans le tunnel, car la requête n'y entre jamais. Le nom d'hôte se résout vers l'adresse publique de la passerelle, et cette adresse n'est joignable que depuis l'extérieur du tunnel qu'elle termine. Corriger cela revient à donner au service une entrée privée plutôt qu'à déplacer le point de terminaison extérieur.

La page se charge de l'extérieur et non par le tunnel

Deux requêtes différentes sont comparées. En données mobiles, le navigateur atteint directement l'adresse publique. Depuis l'intérieur du tunnel, le même nom se résout vers la même adresse publique, et le paquet doit désormais sortir par le tunnel pour atteindre une adresse située du côté opposé du tunnel lui-même. Même nom, même adresse, deux positions très différentes.

Une route de destination choisit une adresse, pas un port. Rien dans la table de routage ne sait que le port 443 sert à l'administration et que le port 1194 est le transport, donc les deux sont traités comme la même destination.

C'est pourquoi la page fonctionne parfois et parfois non, selon le nom et le réseau que le client a utilisés. C'est un problème de chemin et non un problème d'authentification. Les deux clients s'authentifient parfaitement bien.

Gardez le point de terminaison extérieur joignable

Les profils de tunnel complet ont besoin d'une route d'exception pour le point de terminaison VPN, et l'option redirect-gateway d'OpenVPN documente exactement cela : le point de terminaison distant conserve une route via la passerelle préexistante pour que le tunnel ne route pas vers lui-même. Retirez cette exception et le transport chiffré suit le tunnel, ce qui termine la session en boucle. Cette exception est la raison pour laquelle l'adresse du point de terminaison reste joignable depuis l'intérieur du tunnel.

La conséquence est que l'adresse publique reste joignable depuis le client, ce qui explique aussi pourquoi une requête du navigateur vers cette adresse peut suivre la même exception et sortir sans entrer dans le tunnel. L'exception fait son travail, et le nom fait le dégât.

Lisez la décision de routage plutôt que la liste des interfaces avant de changer quoi que ce soit. Les commandes ci-dessous impriment la décision plutôt que l'inventaire. Exécutez-les depuis le client qui a échoué.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Si la recherche montre la route du point de terminaison via la passerelle physique, le comportement est correct et la page d'administration est simplement envoyée sur le mauvais chemin. C'est le point où la résolution de noms devient le correctif.

Donnez au service un nom privé

Le service a besoin d'un nom qui se résout vers l'adresse de la passerelle à l'intérieur du tunnel, tout en conservant la sémantique de certificat et de nom d'hôte que l'application attend. Un enregistrement de zone privé pour le nom d'administration est la réponse habituelle, et il laisse le nom de transport intact.

Ne repointez pas le nom de transport vers l'adresse interne, car le prochain établissement du tunnel tenterait alors d'atteindre une adresse qui n'existe qu'à l'intérieur d'un tunnel. Cette erreur produit un VPN qui fonctionne exactement une fois.

Vérifiez aussi les deux familles d'adresses, car un enregistrement AAAA laissé derrière peut envoyer le navigateur là où le plan privé n'a jamais couvert.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Adaptez la politique à l'endroit où le processus s'exécute

Un processus natif à l'écoute sur la passerelle est joint par le chemin d'entrée local, donc la chaîne d'entrée et la liaison de la socket décident si la requête est acceptée. Les règles de transfert et le transfert IP ne font pas répondre un écouteur local. Autorisez les sources du tunnel dans la politique d'entrée et confirmez que le processus est lié à une adresse que le tunnel peut atteindre.

Un conteneur publié sur un port de l'hôte suit un chemin différent, car le paquet est traduit en destination puis transféré. Cette requête rencontre la politique de transfert de l'hôte et les règles propres à Docker, c'est pourquoi un écouteur natif qui fonctionne peut coexister avec un conteneur qui refuse le même port.

L'ordre de démarrage compte dans les deux cas, car une liaison vers une adresse qui n'apparaît qu'après la montée du tunnel échoue silencieusement au démarrage.

Vérifiez l'accès privé et un chemin public refusé

Faites une requête nommée fraîche depuis un client autorisé, les contrôles d'identité propres à l'application restant intacts. Essayez ensuite le même service depuis l'extérieur du tunnel et confirmez qu'il ne répond pas. Un nom privé est une commodité et non une restriction, et un écouteur encore lié à l'adresse publique reste exposé. Cette dernière vérification est celle que la plupart des revues sautent.

Lisez les liaisons et l'état du filtre plutôt que le nom d'hôte donné aux utilisateurs. L'exposition est une propriété de la socket et non du nom. Cette distinction survit à chaque changement de DNS.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

Quand la requête interne renvoie la page et que la requête externe expire, le service a un chemin privé délibéré et le transport reste joignable. Quand la requête externe répond encore, l'écouteur ou une entrée de conteneur publiée doit être resserré avant que quiconque décrive le service comme uniquement interne.