Hvilken adresse skal stå i DNS for en server, der er forbundet via VPN?

En hostet server med en installeret VPN ender med at have tre adresser, og kun én af dem hører til hvert af de steder, du er ved at konfigurere. At kopiere nummeret fra et udbyderpanel ind i DNS, ind i en listener eller ind i en allowlist er måden, hvorpå en fungerende tunnel bliver en tjeneste, som ingen kan nå. Denne runbook ordner arbejdet, så hver adresse vælges til et angivet formål. Den viser også de kommandoer, der bekræfter, hvad du faktisk har udgivet.

Kortlæg de tre adresser, før du udgiver noget

Navngiv dem efter funktion. Underlagsadressen er det, maskinen bruger til at nå VPN-endepunktet over internettet, og den er ofte privat bag udbyderens NAT. Tunneladressen lever inde i VPN'et og uddeles af serveren eller klienten afhængigt af produktet. Den offentlige udgang er den adresse, som et eksternt websted logger efter oversættelsen, og den behøver ikke findes på noget interface, du kan forespørge.

Et panel, der viser én offentlig adresse for en maskine, fortæller dig meget lidt om de to andre roller. Underlagsrækkevidde er et krav, ikke et køb: en bærbar bag en hjemmerouter kan nå et hostet VPN-endepunkt uden at eje en offentlig IPv4-adresse. Det, du ikke kan, er at opfinde en indgående vej ved at skrive et navn, der peger på en adresse, som ingen videresender.

Vælg adressen efter tjenesten, ikke efter etiketten

Skriv ned, hvad serveren skal gøre, før du vælger et nummer. Udgående API-kald har brug for en stabil udgang, når den anden side fører en allowlist. Privat adgang har brug for en tunneladresse, som klienter kan route til, og en listener, der er bundet til den. Offentlig hosting har brug for en indgående mapping, som udbyderen faktisk tilbyder, og det leverer udgangsadressen alene ikke.

En enkelt maskine kan tjene alle tre formål og stadig bruge tre forskellige adresser. Det, der bryder, er antagelsen om, at én værdi dækker dem alle:

Den indgående række er den, folk diskuterer. En record, der peger på udgangsadressen, opretter ingen listener, ingen firewallåbning og ingen portmapping, og ventetid ændrer ikke ved det. Når udbyderen sælger en dedikeret adresse sammen med en indgående regel, er den pakke den kapacitet, du købte; adressen alene er ikke rettigheden.

Kommandoer, der viser, hvilken adresse der er hvilken

Læs maskinen, ikke panelet. Interface-navne er forskellige mellem systemer, så knyt adresser til enheder i stedet for at stole på en etiket.

Den første linje viser hver IPv4-adresse og dens enhed, og den anden spørger kernen, hvilken enhed den ville bruge til en kendt destination udenfor:

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)'

Hvis routeopslaget svarer med en tunnelenhed for offentlig trafik, virker din fulde tunnel. Listenerkontrollen er lige så vigtig, for en proces, der kun er bundet til 127.0.0.1, vil aldrig svare på tunneladressen, uanset hvilket navn du udgiver.

Udgiv den, og bekræft derefter udefra

Udgiv den værdi, tjenesten har brug for, og ikke mere: en A- eller AAAA-record til hosting, en allowlist-post til udgående kald, en klientprofil til privat adgang. Test derefter fra den position, der betyder noget, og det er aldrig den maskine, du lige har redigeret.

To kontroller dækker det meste, og begge er billige nok til at blive i et script:

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

Et DNS-svar, der beviser, at din record findes, er ikke bevis for, at en anmodning ankommer, og én vellykket anmodning beviser kun, at én vej virker fra ét netværk. Gentag kontrollen over en mobilforbindelse, når en allowlist er involveret, for den udgang, du ser, kan afhænge af adressefamilien og den valgte rute. Noter, hvilken familie du bekræftede; en fungerende IPv4-vej siger intet som helst om IPv6.

Hvis tjenesten er indgående, er udgangsadressen ikke nok

Indgående adgang har brug for fire ting på linje: et navn eller en adresse, som en klient kan nå, en rute, der leverer pakken til maskinen, en listener, der accepterer den, og en politik, der ikke dropper den. En VPN ændrer det andet element og nogle gange det første, og den gør intet for det tredje og fjerde. Når tunnelen er leveringsvejen, forbinder klienter til tunneladressen, ikke til udgangen.

Noter, hvilken adresse hver tjeneste afhænger af, og gennemgå den note, hver gang udbyderen ændrer sin routingmodel. En server, der svarer privat og fejler offentligt, er normalt ikke i stykker; den svarer på den forkerte identitet, og reparationen er en mappingbeslutning og ikke en firewallændring.