Kva adresse skal stå i DNS for ein tenar som er kopla til via VPN?

Ein hosta tenar med installert VPN endar opp med tre adresser, og berre éi av dei høyrer heime på kvar stad du er i ferd med å konfigurere. Å kopiere nummeret frå eit leverandørpanel inn i DNS, inn i ein lyttar eller inn i ei allowliste er måten ein fungerande tunnel blir ei teneste ingen kan nå. Denne runboka ordnar arbeidet slik at kvar adresse blir vald for eit angitt føremål. Ho listar òg kommandoane som stadfestar kva du faktisk publiserte.

Kartlegg dei tre adressene før du publiserer noko

Namngi dei etter funksjon. Underlagsadressa er det maskina brukar for å nå VPN-endepunktet over internett, og ho er ofte privat bak NAT-en til leverandøren. Tunneladressa lever inne i VPN-et og blir delt ut av tenaren eller klienten avhengig av produktet. Den offentlege utgangen er adressa eit eksternt nettstad loggar etter omsetjinga, og ho treng ikkje finnast på noko grensesnitt du kan spørje.

Eit panel som viser éi offentleg adresse for ei maskin fortel deg svært lite om dei to andre rollene. Underlagsnåbarheit er eit krav, ikkje eit kjøp: ein berbar PC bak ein heimeruter kan nå eit hosta VPN-endepunkt utan å eige ei offentleg IPv4-adresse. Det du ikkje kan, er å finne opp ein inngåande veg ved å skrive eit namn som peikar på ei adresse ingen videresender.

Vel adressa etter tenesta, ikkje etter etiketten

Skriv ned kva tenaren må gjere før du vel eit nummer. Utgåande API-kall treng ein stabil utgang når motparten fører ei allowliste. Privat tilgang treng ei tunneladresse klientar kan rute til og ein lyttar bunden til henne. Offentleg hosting treng ein inngåande mapping som leverandøren faktisk tilbyr, og det gir ikkje utgangsadressa åleine.

Éi maskin kan tene alle tre føremåla og likevel bruke tre ulike adresser. Det som bryt saman, er antakinga om at éin verdi dekkjer dei alle:

Den inngåande rada er den folk kranglar om. Ein record som peikar på utgangsadressa lagar ingen lyttar, inga brannmur-opning og ingen portmapping, og å vente endrar ikkje det. Når leverandøren sel ei dedikert adresse saman med ei inngåande regel, er den pakken den kapasiteten du kjøpte; adressa åleine er ikkje rettigheita.

Kommandoar som viser kva adresse som er kva

Les maskina, ikkje panelet. Grensesnittnamn er ulike mellom system, så kople adresser til einingar i staden for å stole på ein etikett.

Den første linja viser kvar IPv4-adresse og eininga ho høyrer til, og den andre spør kjernen kva eining han ville bruke for ein kjend destinasjon utanfor:

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

Viss rutesøket svarar med ei tunneleining for offentleg trafikk, er den fulle tunnelen aktiv. Lyttarkontrollen er like viktig, for ein prosess som berre er bunden til 127.0.0.1 vil aldri svare på tunneladressa, uansett kva namn du publiserer.

Publiser henne, og stadfest så utanfrå

Publiser verdien tenesta treng og ikkje noko meir: ein A- eller AAAA-record for hosting, ei allowliste-oppføring for utgåande kall, ein klientprofil for privat tilgang. Test så frå posisjonen som betyr noko, og det er aldri maskina du nettopp redigerte.

To kontrollar dekkjer det meste, og begge er billege nok til å halde i eit skript:

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

Eit DNS-svar som bevisar at recorden din finst, er ikkje bevis for at ein førespurnad kjem fram, og éin vellukka førespurnad bevisar berre at éin veg verkar frå eitt nettverk. Gjenta kontrollen over ei mobilteneste når ei allowliste er involvert, for utgangen du ser kan avhenge av adressefamilien og ruta som vart vald. Noter kva familie du stadfesta; ein fungerande IPv4-veg seier ingenting i det heile om IPv6.

Viss tenesta er inngåande, er ikkje utgangsadressa nok

Inngåande tilgang treng fire ting på linje: eit namn eller ei adresse ein klient kan nå, ei rute som leverer pakken til maskina, ein lyttar som godtek han, og ein policy som ikkje droppar han. Eit VPN endrar det andre elementet og nokre gonger det første, og det gjer ingenting for det tredje og fjerde. Når tunnelen er leveringsvegen, koplar klientar til tunneladressa, ikkje til utgangen.

Noter kva adresse kvar teneste er avhengig av, og gå gjennom notatet på nytt når leverandøren endrar rutingsmodellen sin. Ein tenar som svarar privat og feilar offentleg, er som regel ikkje øydelagd; han svarar på feil identitet, og reparasjonen er eit mapping-val og ikkje ei brannmur-endring.