Qual endereço vai no DNS para um servidor conectado por VPN?

Um servidor hospedado com uma VPN instalada acaba por ter três endereços, e apenas um deles pertence a cada local que está prestes a configurar. Copiar o número de um painel do fornecedor para o DNS, para um listener ou para uma lista de permissões é a forma como um túnel que funcionava se transforma num serviço que ninguém consegue alcançar. Este guia ordena o trabalho para que cada endereço seja escolhido com um propósito declarado. Também lista os comandos que confirmam o que você realmente publicou.

Mapeie os três endereços antes de publicar qualquer coisa

Nomeie-os pela função. O endereço de underlay é o que a máquina usa para alcançar o endpoint da VPN através da internet, e muitas vezes é privado atrás do NAT do fornecedor. O endereço de túnel vive dentro da VPN, atribuído pelo servidor ou pelo cliente conforme o produto. A saída pública é o endereço que um site remoto registra após a tradução, e não precisa de existir em nenhuma interface que você possa consultar.

Um painel que mostra um endereço público para uma máquina diz muito pouco sobre os outros dois papéis. A alcançabilidade do underlay é um requisito, não uma compra: um portátil atrás de um router doméstico pode alcançar um endpoint VPN hospedado sem possuir um endereço IPv4 público. O que não pode fazer é inventar um caminho de entrada escrevendo um nome que resolve para um endereço que ninguém encaminha.

Escolha o endereço pelo serviço, não pelo rótulo

Anote o que o servidor tem de fazer antes de escolher um número. As chamadas de API de saída precisam de uma saída estável quando o outro lado mantém uma lista de permissões. O acesso privado precisa de um endereço de túnel para o qual os clientes possam encaminhar e de um listener ligado a ele. A hospedagem pública precisa de um mapeamento de entrada que o fornecedor ofereça na prática, e o endereço de saída sozinho não o fornece.

Uma única máquina pode servir os três propósitos e ainda usar três endereços diferentes. O que se quebra é a suposição de que um valor cobre todos eles:

A linha de entrada é aquela sobre a qual as pessoas discutem. Um registro que aponta para o endereço de saída não cria listener, nem abertura de firewall, nem mapeamento de porta, e esperar não muda isso. Quando o fornecedor vende um endereço dedicado junto com uma regra de entrada, esse pacote é a capacidade que você comprou; o endereço sozinho não é o direito.

Comandos que mostram qual endereço é qual

Leia a máquina, não o painel. Os nomes das interfaces diferem entre sistemas, por isso associe os endereços aos dispositivos em vez de confiar num rótulo.

A primeira linha lista cada endereço IPv4 e o seu dispositivo, e a segunda pergunta ao kernel qual dispositivo usaria para um destino externo conhecido:

ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'

Se a consulta de rota responder com um dispositivo de túnel para o tráfego público, o seu túnel completo está em vigor. A verificação do listener importa tanto quanto, porque um processo ligado apenas a 127.0.0.1 nunca responderá no endereço de túnel, seja qual for o nome que publicar.

Publique o endereço e depois verifique de fora

Publique o valor de que o serviço precisa e nada mais: um registro A ou AAAA para hospedagem, uma entrada na lista de permissões para chamadas de saída, um perfil de cliente para acesso privado. Depois teste a partir da posição que importa, e essa nunca é a máquina que você acabou de editar.

Duas verificações cobrem a maior parte, e ambas são baratas o suficiente para ficarem num script:

dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/health

Uma resposta DNS que prova que o seu registro existe não é prova de que um pedido chega, e um pedido bem-sucedido prova apenas que um caminho funciona a partir de uma rede. Repita a verificação a partir de uma ligação móvel quando houver uma lista de permissões envolvida, porque a saída que observa pode depender da família de endereços e da rota seguida. Anote qual família verificou; um caminho IPv4 funcional não diz absolutamente nada sobre IPv6.

Se o serviço for de entrada, o endereço de saída não basta

O acesso de entrada precisa de quatro coisas alinhadas: um nome ou endereço que um cliente possa alcançar, uma rota que entregue o pacote à máquina, um listener que o aceite e uma política que não o descarte. Uma VPN muda o segundo item e às vezes o primeiro, e não faz nada pelo terceiro e pelo quarto. Quando o túnel é o caminho de entrega, os clientes ligam-se ao endereço de túnel, não à saída.

Registe de qual endereço cada serviço depende e reveja essa nota sempre que o fornecedor mudar o seu modelo de encaminhamento. Um servidor que responde em privado e falha em público normalmente não está avariado; está a responder com a identidade errada, e a reparação é uma decisão de mapeamento e não uma alteração de firewall.