Vilken adress ska stå i DNS för en server som är ansluten via VPN?

En hostad server med en installerad VPN hamnar med tre adresser, och bara en av dem hör hemma på varje plats du är på väg att konfigurera. Att kopiera numret från en leverantörspanel till DNS, till en lyssnare eller till en allowlista är hur en fungerande tunnel blir en tjänst som ingen kan nå. Den här runboken ordnar arbetet så att varje adress väljs för ett angivet syfte. Den listar också kommandona som bekräftar vad du faktiskt publicerade.

Kartlägg de tre adresserna innan du publicerar något

Namnge dem efter funktion. Underlagsadressen är det maskinen använder för att nå VPN-slutpunkten över internet, och den är ofta privat bakom leverantörens NAT. Tunneladressen lever inuti VPN:en och delas ut av servern eller klienten beroende på produkten. Den offentliga utgången är den adress som en extern webbplats loggar efter översättningen, och den behöver inte finnas på något gränssnitt du kan fråga.

En panel som visar en offentlig adress för en maskin berättar väldigt lite om de andra två rollerna. Underlagsnåbarhet är ett krav, inte ett köp: en bärbar dator bakom en hemrouter kan nå en hostad VPN-slutpunkt utan att äga en offentlig IPv4-adress. Det du inte kan är att hitta på en inkommande väg genom att skriva ett namn som pekar på en adress som ingen vidarebefordrar.

Välj adressen efter tjänsten, inte efter etiketten

Skriv ner vad servern måste göra innan du väljer ett nummer. Utgående API-anrop behöver en stabil utgång när motparten för en allowlista. Privat åtkomst behöver en tunneladress som klienter kan routa till och en lyssnare bunden till den. Offentlig hosting behöver en inkommande mappning som leverantören faktiskt erbjuder, och det ger inte utgångsadressen ensam.

En enda maskin kan tjäna alla tre syftena och ändå använda tre olika adresser. Det som brister är antagandet att ett värde täcker dem alla:

Den inkommande raden är den folk bråkar om. En record som pekar på utgångsadressen skapar ingen lyssnare, ingen brandväggsöppning och ingen portmappning, och att vänta ändrar inte det. När leverantören säljer en dedikerad adress tillsammans med en inkommande regel är det paketet den förmåga du köpte; adressen i sig är inte rättigheten.

Kommandon som visar vilken adress som är vilken

Läs maskinen, inte panelen. Gränssnittsnamn skiljer sig mellan system, så koppla adresser till enheter i stället för att lita på en etikett.

Den första raden listar varje IPv4-adress och dess enhet, och den andra frågar kärnan vilken enhet den skulle använda för en känd destination utanför:

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

Om routeuppslaget svarar med en tunnelenhet för offentlig trafik är din fulla tunnel aktiv. Lyssnarkontrollen är lika viktig, för en process som bara är bunden till 127.0.0.1 kommer aldrig att svara på tunneladressen, oavsett vilket namn du publicerar.

Publicera den, verifiera sedan utifrån

Publicera det värde tjänsten behöver och inget mer: en A- eller AAAA-record för hosting, en allowlista-post för utgående anrop, en klientprofil för privat åtkomst. Testa sedan från den position som betyder något, och det är aldrig maskinen du just redigerade.

Två kontroller täcker det mesta, och båda är billiga nog att behålla i ett skript:

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

Ett DNS-svar som bevisar att din record finns är inte bevis för att en begäran kommer fram, och en lyckad begäran bevisar bara att en väg fungerar från ett nätverk. Upprepa kontrollen över en mobilanslutning när en allowlista är inblandad, för den utgång du ser kan bero på adressfamiljen och den valda rutten. Notera vilken familj du verifierade; en fungerande IPv4-väg säger ingenting alls om IPv6.

Om tjänsten är inkommande räcker inte utgångsadressen

Inkommande åtkomst behöver fyra saker i linje: ett namn eller en adress som en klient kan nå, en rutt som levererar paketet till maskinen, en lyssnare som accepterar det och en policy som inte släpper det. En VPN ändrar den andra posten och ibland den första, och den gör ingenting för den tredje och fjärde. När tunneln är leveransvägen ansluter klienter till tunneladressen, inte till utgången.

Anteckna vilken adress varje tjänst är beroende av och gå igenom anteckningen igen när leverantören ändrar sin routingmodell. En server som svarar privat och misslyckas offentligt är oftast inte trasig; den svarar på fel identitet, och reparationen är ett mappningsbeslut och inte en brandväggsändring.