Welk adres hoort in DNS voor een server die via VPN is verbonden?

Een gehoste server met een VPN erop houdt uiteindelijk drie adressen vast, en slechts één daarvan hoort op elke plek die je gaat configureren. Het nummer uit een providerdashboard naar DNS kopiëren, naar een listener of naar een allowlist, is hoe een werkende tunnel een dienst wordt die niemand kan bereiken. Deze runbook ordert het werk zo dat elk adres voor een genoemd doel wordt gekozen. Hij somt ook de commando's op die bevestigen wat je daadwerkelijk hebt gepubliceerd.

Breng de drie adressen in kaart voordat je iets publiceert

Noem ze naar functie. Het underlay-adres is wat de machine gebruikt om het VPN-eindpunt over het internet te bereiken, en het is vaak privé achter NAT van de provider. Het tunneladres leeft binnen de VPN en wordt afhankelijk van het product door de server of de client uitgegeven. De publieke uitgang is het adres dat een externe website na de vertaling vastlegt, en het hoeft op geen enkele interface te bestaan die je kunt opvragen.

Een dashboard dat één publiek adres voor een machine toont, vertelt je heel weinig over de andere twee rollen. Underlay-bereikbaarheid is een vereiste, geen aankoop: een laptop achter een thuisrouter kan een gehost VPN-eindpunt bereiken zonder een publiek IPv4-adres te bezitten. Wat je niet kunt, is een inkomend pad verzinnen door een naam te schrijven die naar een adres verwijst dat niemand doorstuurt.

Kies het adres op basis van de dienst, niet van het label

Schrijf op wat de server moet doen voordat je een nummer kiest. Uitgaande API-aanroepen hebben een stabiele uitgang nodig wanneer de andere kant een allowlist bijhoudt. Privétoegang heeft een tunneladres nodig waar clients naartoe kunnen routeren en een listener die daaraan gebonden is. Openbaar hosten heeft een inkomende mapping nodig die de provider echt biedt, en die levert het uitgangsadres alleen niet.

Eén machine kan alle drie de doelen dienen en toch drie verschillende adressen gebruiken. Wat breekt, is de aanname dat één waarde ze allemaal dekt:

De inkomende rij is degene waarover mensen discussiëren. Een record dat naar het uitgangsadres wijst, maakt geen listener, geen firewallopening en geen portmapping, en wachten verandert daar niets aan. Wanneer de provider een toegewijd adres samen met een inkomende regel verkoopt, is dat bundel de capaciteit die je hebt gekocht; het adres op zich is niet de aanspraak.

Commando's die laten zien welk adres welk is

Lees de machine, niet het dashboard. Interfacenamen verschillen per systeem, dus koppel adressen aan apparaten in plaats van een label te vertrouwen.

De eerste regel somt elk IPv4-adres en het bijbehorende apparaat op, en de tweede vraagt de kernel welk apparaat hij voor een bekend doel buiten zou gebruiken:

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

Als de routeopzoeking voor openbaar verkeer met een tunnelapparaat antwoordt, is je volledige tunnel actief. De listenercontrole is even belangrijk, want een proces dat alleen aan 127.0.0.1 gebonden is, zal nooit op het tunneladres antwoorden, ongeacht welke naam je publiceert.

Publiceer het, en controleer dan vanaf buiten

Publiceer de waarde die de dienst nodig heeft en niets meer: een A- of AAAA-record voor hosten, een allowlist-vermelding voor uitgaande aanroepen, een clientprofiel voor privétoegang. Test daarna vanaf de positie die ertoe doet, en dat is nooit de machine die je net hebt aangepast.

Twee controles dekken het meeste, en beide zijn goedkoop genoeg om in een script te bewaren:

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

Een DNS-antwoord dat bewijst dat je record bestaat, is geen bewijs dat een verzoek aankomt, en één geslaagd verzoek bewijst alleen dat één pad vanaf één netwerk werkt. Herhaal de controle via een mobiele verbinding wanneer er een allowlist in het spel is, want de uitgang die je ziet kan afhangen van de adresfamilie en de gevolgde route. Noteer welke familie je hebt geverifieerd; een werkend IPv4-pad zegt helemaal niets over IPv6.

Als de dienst inkomend is, is het uitgangsadres niet genoeg

Inkomende toegang heeft vier dingen op een rij nodig: een naam of adres dat een client kan bereiken, een route die het pakket bij de machine brengt, een listener die het aanneemt en een beleid dat het niet laat vallen. Een VPN verandert het tweede item en soms het eerste, en het doet niets voor het derde en vierde. Wanneer de tunnel het afleverpad is, verbinden clients zich met het tunneladres, niet met de uitgang.

Leg vast van welk adres elke dienst afhangt en bekijk dat overzicht opnieuw wanneer de provider zijn routingmodel wijzigt. Een server die privé antwoordt en publiek faalt, is meestal niet kapot; hij antwoordt onder de verkeerde identiteit, en de reparatie is een mappingbeslissing en geen firewallwijziging.