A pasarela aloxa a súa propia páxina de administración: enderezo interno ou público

Unha páxina de administración responde desde un teléfono con datos móbiles e caduca desde un portátil unido á VPN. Nada do túnel está roto, porque a petición nunca entra nel. O nome de host resólvese no enderezo público da pasarela, e ese enderezo só é acadable desde fóra do túnel que esta remata. Arranxalo significa darlle ao servizo unha entrada privada en lugar de mover o extremo exterior.

A páxina carga desde fóra e non a través do túnel

Compáranse dúas peticións distintas. Con datos móbiles, o navegador chega directamente ao enderezo público. Desde dentro do túnel, o mesmo nome resólvese no mesmo enderezo público, e o paquete agora ten que saír polo túnel para acadar un enderezo no propio lado afastado do túnel. Mesmo nome, mesmo enderezo, dúas posicións moi distintas.

Unha ruta de destino escolle un enderezo, non un porto. Nada na táboa de encamiñamento sabe que o porto 443 é para administración e o porto 1194 é o transporte, así que ambos se tratan como o mesmo destino.

Por iso a páxina ás veces funciona e ás veces non, segundo que nome e que rede usase o cliente. É un problema de camiño e non un problema de autenticación. Ambos os clientes se autentican perfectamente.

Manteña acadable o extremo exterior

Os perfís de túnel completo necesitan unha ruta de excepción para o extremo da VPN, e a opción redirect-gateway de OpenVPN documenta exactamente iso: o extremo remoto conserva unha ruta a través da pasarela preexistente para que o túnel non encamiñe cara a si mesmo. Quite esa excepción e o transporte cifrado segue o túnel, o que remata a sesión nun bucle. Esa excepción é a razón pola que o enderezo do extremo segue sendo acadable desde dentro do túnel.

A consecuencia é que o enderezo público segue sendo acadable desde o cliente, e por iso unha petición do navegador a ese enderezo pode seguir a mesma excepción e saír sen entrar no túnel. A excepción fai o seu traballo, e o nome fai o dano.

Lea a decisión da ruta en lugar da lista de interfaces antes de cambiar nada. Os comandos de abaixo imprimen a decisión en lugar do inventario. Execúteos desde o cliente que fallou.

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

Se a consulta mostra a ruta do extremo a través da pasarela física, o comportamento é correcto e a páxina de administración simplemente se envía polo camiño equivocado. Ese é o punto no que a resolución de nomes se converte na solución.

Déalle ao servizo un nome privado

O servizo necesita un nome que se resolva no enderezo da pasarela dentro do túnel, mantendo á vez a semántica de certificado e de nome de host que a aplicación espera. Un rexistro de zona privado para o nome de administración é a resposta habitual, e deixa intacto o nome de transporte.

Non reapunte o nome de transporte ao enderezo interno, porque o seguinte establecemento do túnel tentaría entón acadar un enderezo que só existe dentro dun túnel. Ese erro produce unha VPN que funciona exactamente unha vez.

Comprobe tamén ambas as familias de enderezos, xa que un rexistro AAAA que quede atrás pode enviar o navegador a un lugar que o plan privado nunca cubriu.

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/

Axuste a política a onde se executa o proceso

Un proceso nativo que escoita na pasarela acádase pola ruta de entrada local, así que a cadea de entrada e a vinculación do socket deciden se a petición se acepta. As regras de reenvío e o reenvío IP non fan que un escoitador local responda. Permita as fontes do túnel na política de entrada e confirme que o proceso está vinculado a un enderezo que o túnel pode acadar.

Un contedor publicado nun porto do anfitrión segue un camiño distinto, porque o paquete tradúcese por destino e reenvíase. Esa petición atopa a política de reenvío do anfitrión e as regras propias de Docker, e por iso un escoitador nativo que funciona pode convivir cun contedor que rexeita o mesmo porto.

A orde de arranque importa en ambos os casos, porque unha vinculación a un enderezo que só aparece despois de que o túnel suba falla en silencio ao arrincar.

Comprobe o acceso privado e un camiño público denegado

Faga unha petición nova e nomeada desde un cliente autorizado coas comprobacións de identidade propias da aplicación intactas. Despois probe o mesmo servizo desde fóra do túnel e confirme que non responde. Un nome privado é unha comodidade e non unha restrición, e un escoitador aínda vinculado ao enderezo público segue exposto. Esa última comprobación é a que máis revisións omiten.

Lea as vinculacións e o estado do filtro en lugar do nome de host que recibiron os usuarios. A exposición é unha propiedade do socket e non do nome. Esa distinción sobrevive a cada cambio 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/

Cando a petición interna devolve a páxina e a petición externa caduca, o servizo ten un camiño privado deliberado e o transporte segue sendo acadable. Cando a petición externa segue respondendo, hai que estreitar o escoitador ou unha entrada de contedor publicada antes de que alguén describa o servizo como só interno.