O gateway aloja a sua própria página de administração: endereço interno ou público

Uma página de administração responde a partir de um telemóvel em dados móveis e expira a partir de um portátil ligado à VPN. Nada no túnel está avariado, porque o pedido nunca entra nele. O nome do anfitrião resolve-se para o endereço público do gateway, e esse endereço só é alcançável de fora do túnel que ele termina. Corrigir isto significa dar ao serviço uma entrada privada em vez de deslocar o ponto final exterior.

A página carrega de fora e não através do túnel

Estão a ser comparados dois pedidos diferentes. Em dados móveis, o navegador chega diretamente ao endereço público. Do interior do túnel, o mesmo nome resolve-se para o mesmo endereço público, e o pacote tem agora de sair pelo túnel para alcançar um endereço no próprio lado distante do túnel. Mesmo nome, mesmo endereço, duas posições muito diferentes.

Uma rota de destino escolhe um endereço, não uma porta. Nada na tabela de encaminhamento sabe que a porta 443 é para administração e a porta 1194 é o transporte, por isso ambas são tratadas como o mesmo destino.

É por isso que a página às vezes funciona e outras não, dependendo do nome e da rede que o cliente usou. É um problema de caminho e não um problema de autenticação. Ambos os clientes se autenticam perfeitamente.

Mantenha o ponto final exterior alcançável

Os perfis de túnel completo precisam de uma rota de exceção para o ponto final da VPN, e a opção redirect-gateway do OpenVPN documenta exatamente isso: o ponto final remoto mantém uma rota através do gateway preexistente para que o túnel não encaminhe para si mesmo. Remova essa exceção e o transporte cifrado segue o túnel, o que termina a sessão num ciclo. É essa exceção que faz com que o endereço do ponto final continue alcançável de dentro do túnel.

A consequência é que o endereço público continua alcançável a partir do cliente, e é também por isso que um pedido do navegador a esse endereço pode seguir a mesma exceção e sair sem entrar no túnel. A exceção faz o seu trabalho, e o nome faz o dano.

Leia a decisão da rota em vez da lista de interfaces antes de mudar algo. Os comandos abaixo imprimem a decisão em vez do inventário. Execute-os a partir do cliente que falhou.

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

Se a consulta mostrar a rota do ponto final através do gateway físico, o comportamento está correto e a página de administração está simplesmente a ser enviada pelo caminho errado. É nesse ponto que a resolução de nomes se torna a correção.

Dê ao serviço um nome privado

O serviço precisa de um nome que se resolva para o endereço do gateway dentro do túnel, mantendo ao mesmo tempo a semântica de certificado e de nome de anfitrião que a aplicação espera. Um registo de zona privado para o nome de administração é a resposta habitual, e deixa o nome do transporte intacto.

Não reaponte o nome do transporte para o endereço interno, porque o próximo estabelecimento do túnel tentaria então alcançar um endereço que só existe dentro de um túnel. Esse erro produz uma VPN que funciona exatamente uma vez.

Verifique também as duas famílias de endereços, porque um registo AAAA deixado para trás pode enviar o navegador para um lugar que o plano privado nunca cobriu.

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/

Ajuste a política ao local onde o processo corre

Um processo nativo à escuta no gateway é alcançado pelo caminho de entrada local, por isso a cadeia de entrada e a ligação do socket decidem se o pedido é aceite. As regras de encaminhamento e o encaminhamento IP não fazem um ouvinte local responder. Permita as origens do túnel na política de entrada e confirme que o processo está ligado a um endereço que o túnel consegue alcançar.

Um contentor publicado numa porta do anfitrião segue um caminho diferente, porque o pacote é traduzido por destino e encaminhado. Esse pedido encontra a política de encaminhamento do anfitrião e as regras próprias do Docker, e é por isso que um ouvinte nativo a funcionar pode coexistir com um contentor que recusa a mesma porta.

A ordem de arranque importa em ambos os casos, porque uma ligação a um endereço que só aparece depois de o túnel subir falha em silêncio no arranque.

Verifique o acesso privado e um caminho público negado

Faça um novo pedido nomeado a partir de um cliente autorizado com as verificações de identidade próprias da aplicação intactas. Depois experimente o mesmo serviço de fora do túnel e confirme que não responde. Um nome privado é uma comodidade e não uma restrição, e um ouvinte ainda ligado ao endereço público continua exposto. É essa última verificação que a maioria das revisões salta.

Leia as ligações e o estado do filtro em vez do nome de anfitrião que os utilizadores receberam. A exposição é uma propriedade do socket e não do nome. Essa distinção sobrevive a cada alteração 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/

Quando o pedido interno devolve a página e o pedido externo expira, o serviço tem um caminho privado deliberado e o transporte continua alcançável. Quando o pedido externo ainda responde, o ouvinte ou uma entrada de contentor publicada tem de ser estreitada antes de alguém descrever o serviço como apenas interno.