Chegar a unha interface web dentro dun contedor VPN: escolla o dono do porto

A aplicación comparte o espazo de nomes da VPN, así que o porto pertence ao contedor VPN. Enlace o oínte correctamente, publique no dono e manteña o camiño estreito.

Non hai nada mal coa aplicación nin nada mal co túnel, e aínda así o panel non carga. Cando un servizo se executa con network_mode: service:vpn, comparte o espazo de nomes de rede do contedor VPN, o que significa que o seu oínte e os seus portos publicados pertencen a ese espazo de nomes e non ao servizo. De aí derivan tres decisións: onde enlaza a aplicación, que contedor publica o porto e canto de estreito é o camiño de xestión. Póñaas na orde equivocada e cada axuste individual parecerá correcto mentres a combinación non pode funcionar.

Quen posúe o espazo de nomes do porto

Nun espazo de nomes compartido, engadir unha entrada ports: ao servizo dependente non fai nada útil, e varias opcións de rede non son compatibles con el por deseño. Publique no contedor que posúe o espazo de nomes. Ese contedor é tamén aquel cuxo enderezo aparece no host, así que a asignación lese como unha entrada e non unha por servizo.

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

Fíxese no enderezo á esquerda da asignación. Enlazar a 127.0.0.1 mantén o porto publicado no loopback do host, que normalmente é o que quere unha interface de xestión. Enlazar a 0.0.0.0 expono en todas as interfaces do host, e iso é unha decisión de seguridade distinta, non unha comodidade.

Faga que a aplicación escoite onde o espazo de nomes o espera

Un oínte enlazado a 127.0.0.1 dentro do espazo de nomes só é accesible desde dentro dese espazo. Os portos publicados do host chegan desde fóra, así que a aplicación debe enlazar un enderezo máis amplo para que a asignación funcione. Ese é un cambio dunha liña na maioría dos servidores, e é o paso que a xente salta despois de copiar unha guía de endurecemento escrita para un despregamento sen contedores.

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

A listaxe de oíntes dentro da aplicación di a verdade sobre o enderezo de enlace, e docker port di que publicou realmente o dono. Se o primeiro mostra 127.0.0.1 e o segundo mostra unha asignación no host, atopou o desaxuste sen tocar a configuración da VPN.

Escolla como entra o camiño de xestión

Hai tres disposicións razoables. Publique no contedor VPN e chegue a el desde o host ou a rede local. Poña un proxy inverso diante do espazo de nomes e dea ao proxy o único porto exposto. Ou manteña o panel accesible só desde dentro do espazo de nomes mediante unha sesión exec ou un túnel SSH, que é a menor exposición e a menor comodidade.

Cal encaixa depende de quen necesita a interface e desde onde. Un só administrador no mesmo host queda servido por un enlace de loopback. Un equipo que chega a ela a través da VPN necesita un camiño deliberado e un dono con nome. Escoller a opción do proxy dálle TLS e rexistros de acceso, a cambio doutro compoñente que manter actualizado.

Abra o porto de xestión sen abrir todo

A propia política de acceso local ou de bloqueo do cliente VPN pode descartar unha solicitude de xestión entrante mesmo mentres o túnel de saída funciona perfectamente. Permita unha excepción documentada para a orixe e o porto previstos, e despois confirme que a protección habitual do túnel non cambiou. Desactivar o interruptor de seguridade para que cargue un panel cambia un control real por unha lapela do navegador.

Deixe activada a autenticación propia da aplicación. Estar dentro dunha pila conectada á VPN non autoriza a cada usuario local nin a cada dispositivo que poida chegar ao host, e un panel de administración sen autenticación detrás dun túnel segue sendo un panel de administración sen autenticación.

Verifique desde o dispositivo de xestión e volva verificar máis tarde

Probe desde a máquina que realmente xestionará o servizo, non desde o host, e despois verifique por separado o camiño de internet que a aplicación necesita. Un éxito de xestión demostra unha dirección e non di nada sobre a saída.

Volva probar despois de que se recree a pila. Un dono de rede substituído cambia o espazo de nomes ao que se adhire a aplicación, e un URL que funcionaba antes dunha actualización pode non apuntar a nada despois. Anote a asignación publicada e o enderezo de enlace para que a próxima reconstrución sexa unha comprobación de dous minutos en lugar dunha investigación repetida.

Artigos relacionados