Geografische DNS en anycast: controleer de VPN-toegang die je krijgt

Een lokaal DNS-antwoord voelt als een opgelost probleem tot de verbinding ergens anders landt. Geografische DNS en anycast proberen allebei het pad te verkorten, en ze nemen die beslissing op basis van verschillende informatie. Geen van beide garandeert dat de gateway die je bereikt bereikbaar is, dat die de identiteit toont die je client verwacht, of dat je sessie een nodewissel overleeft. De controles hieronder scheiden die vier vragen.

Controleer welke locatie de resolver werkelijk rapporteert

Een gezaghebbende server die een topologiegevoelige query beantwoordt, ziet normaal gesproken het adres van de recursieve resolver die vroeg, niet het adres van de persoon die de naam typte. Een gecentraliseerde resolver kan ver van de clients staan die hij bedient, en het antwoord weerspiegelt de resolver en niet hen. Dat is geen defect; zo gedraagt het protocol zich tenzij extra informatie wordt geleverd. de specificatie voor EDNS Client Subnet beschrijft zowel de beperking als de optionele oplossing.

EDNS Client Subnet kan herkomstnetwerkinformatie meedragen wanneer elke deelnemer het ondersteunt en inschakelt. Het is optioneel, het heeft gevolgen voor privacy en caching, en het is geen toestemming om aan te nemen dat een publieke resolver een precieze gebruikerslocatie rapporteert. Vraag de resolverbeheerders voordat je erop ontwerpt.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Controleer wat anycast-routering heeft besloten

Bij anycast adverteren meerdere locaties bereikbaarheid voor één serviceadres, en het netwerk brengt elke client naar de node die zijn routering verkiest. Die keuze wordt gemaakt door BGP en het omringende beleid, niet door afstand op een kaart. Topologische nabijheid betekent over het algemeen ook niet betere round-trip-prestaties, omdat het pad dat kort lijkt overbelast of asymmetrisch kan zijn. Het adres dat je kreeg zegt niets over welke node antwoordde.

Bevestig de bedienende locatie vanaf de servicezijde, of uit een antwoord dat die noemt, in plaats van alleen uit het DNS-antwoord. traceroute -n 198.51.100.20 toont het pad dat je nam en noemt nog steeds niet de host aan het einde ervan, dus lees het als een pad en niet als een antwoord.

Controleer of de sessie een nodewissel overleeft

Een DNS-query is kort en een VPN-sessie is lang, en de twee hebben volkomen verschillende statusvereisten. Routering kan midden in een sessie verschuiven, en als dat gebeurt, kunnen latere pakketten aankomen bij een node die je tunnel nooit heeft gezien. Of dat overleefbaar is, hangt af van de implementatie: gedeelde status, een bewuste herverbinding of een gedocumenteerde storing. Het adres alleen levert geen van die.

Observeer de verschuiving in plaats van die aan te nemen. sudo tcpdump -ni any -c 20 esp toont de buitenste pakketten terwijl het pad verandert, en een plotselinge verandering in het peeradres is de verschuiving die plaatsvindt. Definieer het beoogde gedrag expliciet voor de implementatie die je draait, en test het vervolgens door een padwijziging af te dwingen. Als het ontwerp sessiereplicatie veronderstelt, benoem dan het mechanisme en benoem de storing die het niet dekt.

Controleer of de identiteit nog steeds klopt

Elk toegangspunt moet de identiteit tonen die je clientprofiel verwacht. Een certificaat dat voor de servicenaam is uitgegeven, werkt over nodes heen, terwijl certificaten per node de client dwingen iets nieuws te accepteren, en daar leren gebruikers door waarschuwingen heen te klikken. Houd de verwachte identiteit en het profiel consistent met het toegangsmodel.

Controleer het vanaf een client die een ongebruikelijke node bereikte, want dat is het geval waarin een certificaat per node zichtbaar wordt. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com drukt de keten en de namen af, precies wat de client vergelijkt. Beslis daarna of het profiel moet worden versmald of het certificaatmodel moet veranderen.

Controleer het record, niet alleen het eerste antwoord

Evalueer drie scenario's en schrijf voor elk vier feiten op: normale toegang, één locatie niet beschikbaar en het overeengekomen herstelgeval. De vier feiten zijn de gebruikte resolver, het geretourneerde adres, de locatie die het bediende en een nieuw applicatieresultaat. Dat record scheidt een DNS-selectieprobleem van een gatewayprobleem, een routeringsprobleem of een sessiestatusprobleem. Zonder dat lijken alle vier identiek vanuit de client.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Voer de scenario's uit vanaf representatieve toegangsnetwerken en niet alleen vanaf kantoor, want de hele vraag gaat over welk toegangspunt verschillende clients werkelijk bereiken. Eén netwerk is een steekproef van één.