Naam van VPN-eindpunt versus naam van een privédienst: twee eigenaren

Twee namen kunnen dezelfde vestiging beschrijven en volledig verschillende vragen beantwoorden. vpn.branch.example vertelt een externe peer waar het VPN-eindpunt te vinden is, en het moet worden opgelost voordat er ook maar een tunnel bestaat. inventory.branch.example vertelt een geautoriseerde gebruiker waar een privéapplicatie woont, en het is pas belangrijk als de tunnel actief is. Onderhoud aan het ene doet niets voor het andere.

Benoem beide records voordat je een van beide debugt

Schrijf beide op met hun eigenaren. Voor het eindpunt noteer je wie het openbare adres bijwerkt en hoe de VPN-client zijn antwoord vernieuwt. Voor de dienst noteer je wie het privéadres bezit, welke zone het record bevat en welke resolvers er antwoord op moeten geven.

Die korte lijst voorkomt de meest voorkomende verkeerde diagnose in dit gebied: een werkende vestigingstunnel herstarten om een record te repareren dat er volledig in leeft. De tunnel is het transport voor de dienstnaam; het is niet de autoriteit ervoor.

Als er een wijziging wordt voorgesteld, vraag dan welk van de twee records die raakt. Als niemand dat kan beantwoorden, is de wijziging niet klaar om te plannen.

Het eindpunt moet worden opgelost voordat er ook maar een tunnel bestaat

Stel dat de internetverbinding van de vestiging een nieuw openbaar adres krijgt. De eindpunt-updater publiceert het nieuwe adres, en de externe VPN-implementatie moet het gewijzigde antwoord kunnen lezen. Welke resolver dat antwoord ook levert, die moet zonder de tunnel bereikbaar zijn, anders jaagt de client op een naam die hij pas kan oplossen nadat hij verbinding heeft gemaakt met wat hij niet kan vinden.

Die bootstrap-afhankelijkheid is het waard om ronduit te benoemen, want ze ontstaat gemakkelijk per ongeluk wanneer alle interne resolvers achter de VPN staan. Houd een pad vóór de tunnel aan voor de eindpuntopzoeking, en bevestig het herverbindingsgedrag van de client in plaats van aan te nemen dat een nieuw antwoord meteen wordt opgepikt.

Dynamische DNS heeft ook grenzen die de recordupdate niet kan overschrijden. Een record bijwerken opent geen firewallpoort, maakt geen NAT-mapping en bewijst geen peer-identiteit. Een gepubliceerd adres met een gesloten poort levert een client op die correct oplost en toch met niets kan verbinden.

Tot slot kan een draaiende client een gecacht eindpunt blijven gebruiken tot hij opnieuw verbindt. Scheid publicatie, cache en herverbindingsbeleid in je notities, zodat een verouderde peer niet wordt aangezien voor een kapotte updater.

De dienstnaam beschrijft waar de applicatie woont

Stel nu dat de tunnel gezond blijft, maar de inventarisserver van 172.26.14.20 naar 172.26.14.35 verhuist. Het openbare eindpuntrecord wordt niet beïnvloed, terwijl het privédienstrecord moet veranderen. Een adres gebruiken dat voor die dienst is gereserveerd, of een statische toewijzing, maakt dit zeldzamer; een geautoriseerd updatepad behandelt de keren dat dit bedoeld is.

Hier worden twee updatemechanismen door elkaar gehaald. RFC 2136 definieert een protocol voor het toevoegen en verwijderen van DNS-records in een zone, terwijl een commerciële dynamische DNS-provider een volledig andere HTTP-API voor een ander doel kan aanbieden. Het ene gebruiken betekent niet dat het andere in je omgeving bestaat. Controleer welk mechanisme je zone werkelijk accepteert voordat je er een updater voor schrijft.

Een correct privéantwoord is slechts de eerste voorwaarde. Wil een externe aanroeper het gebruiken, dan heeft de client een resolver nodig die de privézone voert, een beleid dat query's naar die resolver toestaat, en doorsturing voor het adres dat terugkomt. Een naam die oplost naar een adres dat de client niet kan bereiken, levert een time-out op die op een serverfout lijkt.

Test de twee paden apart

Controleer het eindpunt van buiten de tunnel en de dienst van binnenin, en houd de resultaten als twee onafhankelijke feiten:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Als de eerste query mislukt, is het probleem de openbare publicatie of het oplospad vóór de tunnel, en geen enkele interne wijziging helpt. Als de tweede een adres retourneert maar de derde geen route door de tunnel toont, is de DNS-laag in orde en het doorstuurbeleid niet.

Voer het paar na elke adreswijziging uit en noteer welk record is verschoven. Een overdracht die alleen zegt «DNS is bijgewerkt», laat de volgende engineer raden welke van de twee levenscycli werkelijk heeft gelopen.