Que enderezo vai no DNS para un servidor conectado por VPN?

Un servidor aloxado cunha VPN instalada acaba tendo tres enderezos, e só un deles pertence a cada lugar que estás a piques de configurar. Copiar o número dun panel do provedor ao DNS, a un listener ou a unha lista de permisos é como un túnel que funcionaba se converte nun servizo que ninguén pode acadar. Esta guía ordena o traballo para que cada enderezo se escolla cun propósito declarado. Tamén enumera as ordes que confirman o que publicaches realmente.

Mapea os tres enderezos antes de publicar nada

Nomeaos pola función. O enderezo de underlay é o que a máquina usa para acadar o extremo da VPN por internet, e adoita ser privado detrás do NAT do provedor. O enderezo de túnel vive dentro da VPN, asignado polo servidor ou polo cliente segundo o produto. A saída pública é o enderezo que un sitio remoto rexistra despois da tradución, e non precisa existir en ningunha interface que poidas consultar.

Un panel que mostra un enderezo público para unha máquina di moi pouco sobre os outros dous papeis. A alcanzabilidade do underlay é un requisito, non unha compra: un portátil detrás dun router doméstico pode acadar un extremo de VPN aloxado sen posuír un enderezo IPv4 público. O que non podes facer é inventar un camiño de entrada escribindo un nome que resolve a un enderezo que ninguén reenvía.

Escolle o enderezo polo servizo, non pola etiqueta

Anota o que o servidor ten que facer antes de escoller un número. As chamadas de API saíntes precisan unha saída estable cando a outra banda mantén unha lista de permisos. O acceso privado precisa un enderezo de túnel ao que os clientes poidan encamiñar e un listener ligado a el. O aloxamento público precisa unha correspondencia de entrada que o provedor ofreza de verdade, e o enderezo de saída só non a fornece.

Unha soa máquina pode servir os tres propósitos e aínda así usar tres enderezos diferentes. O que se rompe é a suposición de que un valor os cobre todos:

A fila de entrada é a que a xente discute. Un rexistro que apunta ao enderezo de saída non crea listener, nin apertura de firewall, nin correspondencia de porto, e esperar non cambia iso. Cando o provedor vende un enderezo dedicado xunto cunha regra de entrada, ese paquete é a capacidade que compraches; o enderezo só non é o dereito.

Ordes que mostran que enderezo é cal

Le a máquina, non o panel. Os nomes das interfaces difiren entre sistemas, así que emparella os enderezos cos dispositivos en lugar de confiar nunha etiqueta.

A primeira liña lista cada enderezo IPv4 e o seu dispositivo, e a segunda pregúntalle ao núcleo que dispositivo usaría para un destino externo coñecido:

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 ruta responde cun dispositivo de túnel para o tráfico público, o teu túnel completo está en vigor. A comprobación do listener importa igual, porque un proceso ligado só a 127.0.0.1 nunca responderá no enderezo de túnel, publiques o nome que publiques.

Publícao e despois verifica desde fóra

Publica o valor que o servizo necesita e nada máis: un rexistro A ou AAAA para o aloxamento, unha entrada na lista de permisos para as chamadas saíntes, un perfil de cliente para o acceso privado. Despois proba desde a posición que importa, e esa nunca é a máquina que acabas de editar.

Dúas comprobacións cobren a maior parte, e ambas son abondo baratas para mantelas nun script:

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

Unha resposta DNS que demostra que o teu rexistro existe non é proba de que chegue unha petición, e unha petición exitosa só demostra que un camiño funciona desde unha rede. Repite a comprobación desde unha conexión móbil cando haxa unha lista de permisos polo medio, porque a saída que observas pode depender da familia de enderezos e da ruta seguida. Anota que familia verificaches; un camiño IPv4 que funciona non di absolutamente nada sobre IPv6.

Se o servizo é de entrada, o enderezo de saída non abonda

O acceso de entrada necesita catro cousas aliñadas: un nome ou un enderezo que un cliente poida acadar, unha ruta que entregue o paquete á máquina, un listener que o acepte e unha política que non o descarte. Unha VPN cambia o segundo elemento e ás veces o primeiro, e non fai nada polo terceiro e o cuarto. Cando o túnel é a vía de entrega, os clientes conéctanse ao enderezo de túnel, non á saída.

Anota de que enderezo depende cada servizo e revisa esa nota cada vez que o provedor cambie o seu modelo de encamiñamento. Un servidor que responde en privado e falla en público normalmente non está avariado; está respondendo coa identidade equivocada, e a reparación é unha decisión de correspondencia e non un cambio de firewall.