Quina adreça va al DNS per a un servidor connectat per VPN?
Un servidor allotjat té tres adreces i no són intercanviables. Tria el valor que cada servei necessita i confirma’l després des de fora de la màquina.
Un servidor allotjat amb una VPN instal·lada acaba tenint tres adreces, i només una d’elles pertany a cada lloc que estàs a punt de configurar. Copiar el número d’un tauler del proveïdor al DNS, a un listener o a una llista de permisos és com un túnel que funcionava es converteix en un servei que ningú pot assolir. Aquesta guia ordena la feina perquè cada adreça es triï per a un propòsit declarat. També llista les ordres que confirmen el que has publicat realment.
Mapeja les tres adreces abans de publicar res
Anomena-les per funció. L’adreça d’underlay és la que la màquina fa servir per assolir l’extrem de la VPN per internet, i sovint és privada darrere del NAT del proveïdor. L’adreça de túnel viu dins de la VPN, assignada pel servidor o pel client segons el producte. La sortida pública és l’adreça que un lloc remot enregistra després de la traducció, i no cal que existeixi en cap interfície que puguis consultar.
Un tauler que mostra una sola adreça pública per a una màquina diu molt poc sobre els altres dos papers. L’abastabilitat de l’underlay és un requisit, no una compra: un portàtil darrere d’un router domèstic pot assolir un extrem de VPN allotjat sense posseir cap adreça IPv4 pública. El que no pots fer és inventar un camí d’entrada escrivint un nom que resol a una adreça que ningú no reenvia.
Tria l’adreça pel servei, no per l’etiqueta
Anota què ha de fer el servidor abans de triar un número. Les crides d’API sortints necessiten una sortida estable quan l’altra banda manté una llista de permisos. L’accés privat necessita una adreça de túnel a la qual els clients puguin encaminar i un listener lligat a ella. L’allotjament públic necessita un mapatge d’entrada que el proveïdor ofereixi de debò, i l’adreça de sortida sola no el proporciona.
Una sola màquina pot servir els tres propòsits i tot i així fer servir tres adreces diferents. El que es trenca és la suposició que un valor les cobreix totes:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
La fila d’entrada és la que la gent discuteix. Un registre que apunta a l’adreça de sortida no crea cap listener, ni cap obertura de tallafoc, ni cap mapatge de port, i esperar no ho canvia. Quan el proveïdor ven una adreça dedicada juntament amb una regla d’entrada, aquest paquet és la capacitat que has comprat; l’adreça sola no és el dret.
Ordres que mostren quina adreça és quina
Llegeix la màquina, no el tauler. Els noms d’interfície difereixen entre sistemes, així que aparella les adreces amb els dispositius en lloc de confiar en una etiqueta.
La primera línia llista cada adreça IPv4 i el seu dispositiu, i la segona pregunta al nucli quin dispositiu faria servir per a una destinació externa coneguda:
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)'Si la consulta de ruta respon amb un dispositiu de túnel per al trànsit públic, el teu túnel complet està en vigor. La comprovació del listener importa igual, perquè un procés lligat només a 127.0.0.1 no respondrà mai a l’adreça de túnel, publiquis el nom que publiquis.
Publica-la i després verifica des de fora
Publica el valor que el servei necessita i res més: un registre A o AAAA per a l’allotjament, una entrada a la llista de permisos per a les crides sortints, un perfil de client per a l’accés privat. Després prova des de la posició que importa, i aquesta mai no és la màquina que acabes d’editar.
Dues comprovacions cobreixen la major part, i totes dues són prou barates per mantenir-les en un script:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthUna resposta DNS que demostra que el teu registre existeix no és cap prova que arribi una petició, i una petició reeixida només demostra que un camí funciona des d’una xarxa. Repeteix la comprovació des d’una connexió mòbil quan hi hagi una llista de permisos pel mig, perquè la sortida que observes pot dependre de la família d’adreces i de la ruta seguida. Anota quina família has verificat; un camí IPv4 que funciona no diu absolutament res sobre IPv6.
Si el servei és d’entrada, l’adreça de sortida no n’hi ha prou
L’accés d’entrada necessita quatre coses alineades: un nom o una adreça que un client pugui assolir, una ruta que lliuri el paquet a la màquina, un listener que l’accepti i una política que no el descarti. Una VPN canvia el segon element i de vegades el primer, i no fa res pel tercer ni pel quart. Quan el túnel és la via de lliurament, els clients es connecten a l’adreça de túnel, no a la sortida.
Anota de quina adreça depèn cada servei i revisa aquesta nota cada vegada que el proveïdor canviï el seu model d’encaminament. Un servidor que respon en privat i falla en públic normalment no està espatllat; està responent amb la identitat equivocada, i la reparació és una decisió de mapatge i no un canvi de tallafoc.