Hvilken adresse skal stå i DNS for en server som er koblet til via VPN?

En hostet server med installert VPN ender opp med tre adresser, og bare én av dem hører hjemme på hvert sted du er i ferd med å konfigurere. Å kopiere nummeret fra et leverandørpanel inn i DNS, inn i en lytter eller inn i en allowlist er måten en fungerende tunnel blir en tjeneste ingen kan nå. Denne runboken ordner arbeidet slik at hver adresse velges for et angitt formål. Den lister også kommandoene som bekrefter hva du faktisk publiserte.

Kartlegg de tre adressene før du publiserer noe

Navngi dem etter funksjon. Underlagsadressen er det maskinen bruker for å nå VPN-endepunktet over internett, og den er ofte privat bak leverandørens NAT. Tunneladressen lever inne i VPN-et og deles ut av serveren eller klienten avhengig av produktet. Den offentlige utgangen er adressen et eksternt nettsted logger etter oversettelsen, og den trenger ikke finnes på noe grensesnitt du kan spørre.

Et panel som viser én offentlig adresse for en maskin forteller deg svært lite om de to andre rollene. Underlagsnåbarhet er et krav, ikke et kjøp: en bærbar PC bak en hjemmeruter kan nå et hostet VPN-endepunkt uten å eie en offentlig IPv4-adresse. Det du ikke kan, er å finne opp en inngående vei ved å skrive et navn som peker på en adresse ingen videresender.

Velg adressen etter tjenesten, ikke etter etiketten

Skriv ned hva serveren må gjøre før du velger et nummer. Utgående API-kall trenger en stabil utgang når motparten fører en allowlist. Privat tilgang trenger en tunneladresse klienter kan rute til og en lytter bundet til den. Offentlig hosting trenger en inngående mapping som leverandøren faktisk tilbyr, og det gir ikke utgangsadressen alene.

Én maskin kan tjene alle tre formålene og likevel bruke tre forskjellige adresser. Det som bryter sammen, er antakelsen om at én verdi dekker dem alle:

Den inngående raden er den folk krangler om. En record som peker på utgangsadressen lager ingen lytter, ingen brannmuråpning og ingen portmapping, og å vente endrer ikke det. Når leverandøren selger en dedikert adresse sammen med en inngående regel, er den pakken den kapasiteten du kjøpte; adressen alene er ikke rettigheten.

Kommandoer som viser hvilken adresse som er hvilken

Les maskinen, ikke panelet. Grensesnittnavn er forskjellige mellom systemer, så koble adresser til enheter i stedet for å stole på en etikett.

Den første linjen viser hver IPv4-adresse og enheten den hører til, og den andre spør kjernen hvilken enhet den ville bruke for en kjent destinasjon utenfor:

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 rutesøket svarer med en tunnelenhet for offentlig trafikk, er den fulle tunnelen aktiv. Lytterkontrollen er like viktig, for en prosess som bare er bundet til 127.0.0.1 vil aldri svare på tunneladressen, uansett hvilket navn du publiserer.

Publiser den, og bekreft så utenfra

Publiser verdien tjenesten trenger og ikke noe mer: en A- eller AAAA-record for hosting, en allowlist-oppføring for utgående kall, en klientprofil for privat tilgang. Test så fra posisjonen som betyr noe, og det er aldri maskinen du nettopp redigerte.

To kontroller dekker det meste, og begge er billige nok til å holde i et skript:

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

Et DNS-svar som beviser at recorden din finnes, er ikke bevis for at en forespørsel kommer fram, og én vellykket forespørsel beviser bare at én vei virker fra ett nettverk. Gjenta kontrollen over en mobilforbindelse når en allowlist er involvert, for utgangen du ser kan avhenge av adressefamilien og ruten som ble valgt. Noter hvilken familie du bekreftet; en fungerende IPv4-vei sier ingenting i det hele tatt om IPv6.

Hvis tjenesten er inngående, er ikke utgangsadressen nok

Inngående tilgang trenger fire ting på linje: et navn eller en adresse en klient kan nå, en rute som leverer pakken til maskinen, en lytter som aksepterer den, og en policy som ikke dropper den. En VPN endrer det andre elementet og noen ganger det første, og den gjør ingenting for det tredje og fjerde. Når tunnelen er leveringsveien, kobler klienter til tunneladressen, ikke til utgangen.

Noter hvilken adresse hver tjeneste er avhengig av, og gå gjennom notatet på nytt når leverandøren endrer rutingsmodellen sin. En server som svarer privat og feiler offentlig, er som regel ikke ødelagt; den svarer på feil identitet, og reparasjonen er en mappingbeslutning og ikke en brannmur-endring.