Atteindre une interface web dans un conteneur VPN : choisissez le propriétaire du port

L’application partage l’espace de noms du VPN, donc le port appartient au conteneur VPN. Liez correctement l’écouteur, publiez sur le propriétaire et gardez le chemin étroit.

Rien ne cloche dans l’application et rien ne cloche dans le tunnel, et pourtant le tableau de bord ne se charge pas. Quand un service tourne avec network_mode: service:vpn, il partage l’espace de noms réseau du conteneur VPN, ce qui signifie que son écouteur et ses ports publiés appartiennent à cet espace de noms et non au service. Trois décisions en découlent : où l’application se lie, quel conteneur publie le port et à quel point le chemin de gestion est étroit. Mettez-les dans le mauvais ordre et chaque réglage pris isolément paraît correct, alors que la combinaison ne peut pas fonctionner.

Qui possède l’espace de noms du port

Dans un espace de noms partagé, ajouter une entrée ports: au service dépendant ne sert à rien, et plusieurs options réseau ne sont pas prises en charge pour lui par conception. Publiez plutôt sur le conteneur qui possède l’espace de noms. Ce conteneur est aussi celui dont l’adresse apparaît sur l’hôte, donc le mappage se lit comme une seule entrée et non une par service.

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

Remarquez l’adresse à gauche du mappage. Se lier à 127.0.0.1 garde le port publié sur le loopback de l’hôte, ce qu’une interface de gestion veut généralement. Se lier à 0.0.0.0 l’expose sur toutes les interfaces de l’hôte, et c’est une décision de sécurité différente, pas une commodité.

Faites écouter l’application là où l’espace de noms l’attend

Un écouteur lié à 127.0.0.1 à l’intérieur de l’espace de noms n’est joignable que depuis cet espace de noms. Les ports publiés de l’hôte arrivent de l’extérieur, donc l’application doit se lier à une adresse plus large pour que le mappage fonctionne. C’est un changement d’une ligne sur la plupart des serveurs, et c’est précisément l’étape que les gens sautent après avoir copié un guide de durcissement écrit pour un déploiement sans conteneur.

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

La liste des écouteurs dans l’application dit la vérité sur l’adresse de liaison, et docker port dit ce que le propriétaire a réellement publié. Si le premier montre 127.0.0.1 et le second montre un mappage sur l’hôte, vous avez trouvé l’incohérence sans toucher à la configuration du VPN.

Choisissez comment le chemin de gestion entre

Trois dispositions raisonnables existent. Publiez sur le conteneur VPN et atteignez-le depuis l’hôte ou le réseau local. Placez un proxy inverse devant l’espace de noms et donnez au proxy le seul port exposé. Ou gardez le tableau de bord accessible uniquement depuis l’intérieur de l’espace de noms via une session exec ou un tunnel SSH, ce qui est la plus petite exposition et le moins de confort.

Laquelle convient dépend de qui a besoin de l’interface et depuis où. Un seul administrateur sur le même hôte se contente d’une liaison loopback. Une équipe qui y accède par le VPN a besoin d’un chemin réfléchi et d’un propriétaire nommé. Choisir l’option proxy vous apporte TLS et des journaux d’accès, au prix d’un composant de plus à maintenir à jour.

Ouvrez le port de gestion sans tout ouvrir

La politique d’accès local ou de verrouillage du client VPN peut rejeter une demande de gestion entrante même lorsque le tunnel sortant fonctionne parfaitement. Autorisez une exception documentée pour la source et le port prévus, puis confirmez que la protection ordinaire du tunnel est inchangée. Désactiver le kill switch pour faire charger un tableau de bord échange un contrôle réel contre un onglet de navigateur.

Laissez l’authentification propre à l’application activée. Être dans une pile connectée au VPN n’autorise ni chaque utilisateur local ni chaque appareil qui peut atteindre l’hôte, et un panneau d’administration sans authentification derrière un tunnel reste un panneau d’administration sans authentification.

Vérifiez depuis l’appareil de gestion, puis vérifiez de nouveau plus tard

Testez depuis la machine qui gérera réellement le service, pas depuis l’hôte, puis vérifiez séparément le chemin internet dont l’application a besoin. Un succès de gestion prouve une direction et ne dit rien sur la sortie.

Retestez après la recréation de la pile. Un propriétaire réseau remplacé change l’espace de noms auquel l’application se rattache, et une URL qui fonctionnait avant une mise à jour peut ensuite ne plus pointer nulle part. Notez le mappage publié et l’adresse de liaison pour que la prochaine reconstruction soit une vérification de deux minutes au lieu d’une enquête répétée.

Articles similaires