Geografiese DNS en anycast: die VPN-ingang wat jy kry, nagegaan

’n Nabye DNS-antwoord voel soos ’n opgeloste probleem totdat die verbinding elders beland. Geografiese DNS en anycast probeer albei die pad verkort, en hulle neem daardie besluit op grond van verskillende inligting. Nie een waarborg dat die gateway wat jy bereik bereikbaar is nie, dat dit die identiteit toon wat jou kliënt verwag nie, of dat jou sessie ’n nodusverandering oorleef nie. Die kontroles hieronder skei daardie vier vrae.

Kyk wie se ligging die oplosser werklik rapporteer

’n Gesaghebbende bediener wat ’n topologie-sensitiewe navraag beantwoord, sien normaalweg die adres van die rekursiewe oplosser wat gevra het, nie die adres van die persoon wat die naam getik het nie. ’n Gesentraliseerde oplosser kan ver van die kliënte sit wat hy bedien, en die antwoord weerspieël die oplosser eerder as hulle. Dit is nie ’n gebrek nie; dit is hoe die protokol optree tensy ekstra inligting verskaf word. Die EDNS Client Subnet-spesifikasie beskryf beide die beperking en die opsionele oplossing.

EDNS Client Subnet kan inligting oor die oorsprongsnetwerk dra wanneer elke deelnemer dit ondersteun en aktiveer. Dit is opsioneel, dit het privaatheid- en kasgevolge, en dit is nie ’n lisensie om te aanvaar dat enige publieke oplosser ’n presiese gebruikersligging rapporteer nie. Vra die oplosser-operateurs voordat jy daarom ontwerp.

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

Kyk wat anycast-roetering besluit het

Met anycast adverteer verskeie liggings bereikbaarheid vir een diensadres, en die netwerk lewer elke kliënt by watter nodus sy roetering ook al verkies. Daardie keuse word deur BGP en die omliggende beleid gemaak, nie deur afstand op ’n kaart nie. Topologiese nabyheid is ook nie noodwendig gelyk aan beter rondtogprestasie nie, want die pad wat kort lyk, kan oorlaai of asimmetries wees. Die adres wat jy gekry het, sê niks oor watter nodus geantwoord het nie.

Bevestig die bedieningsligging van die dienskant af, of uit ’n antwoord wat dit noem, eerder as uit die DNS-antwoord alleen. traceroute -n 198.51.100.20 wys die pad wat jy gevolg het en noem steeds nie die gasheer aan die einde daarvan nie, so lees dit as ’n pad eerder as ’n antwoord.

Kyk dat die sessie ’n nodusverandering oorleef

’n DNS-navraag is kort en ’n VPN-sessie is lank, en die twee het heeltemal verskillende toestandvereistes. Roetering kan midde-in die sessie verskuif, en wanneer dit gebeur, kan latere pakkette by ’n nodus aankom wat jou tonnel nog nooit gesien het nie. Of dit oorleefbaar is, hang van die implementering af: gedeelde toestand, ’n doelbewuste herverbinding, of ’n gedokumenteerde mislukking. Die adres alleen verskaf nie een daarvan nie.

Neem die verskuiwing waar eerder as om dit te aanvaar. sudo tcpdump -ni any -c 20 esp wys die buitenste pakkette soos die pad verander, en ’n skielike verandering in die eweknie-adres is die verskuiwing wat gebeur. Definieer die bedoelde gedrag eksplisiet vir die implementering wat jy bedryf, en toets dit dan deur ’n padverandering te forseer. As die ontwerp sessiereplikasie veronderstel, noem die meganisme en noem die mislukking wat dit nie dek nie.

Kyk dat die identiteit steeds pas

Elke ingangspunt moet die identiteit toon wat jou kliëntprofiel verwag. ’n Sertifikaat wat vir die diensnaam uitgereik is, werk oor nodusse heen, terwyl sertifikate per nodus die kliënt dwing om iets nuuts te aanvaar, en dit is waar gebruikers leer om deur waarskuwings te klik. Hou die verwagte identiteit en die profiel in ooreenstemming met die ingangsmodel.

Kontroleer dit vanaf ’n kliënt wat ’n ongewone nodus bereik het, want dit is die geval waar ’n sertifikaat per nodus sigbaar word. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com druk die ketting en die name, wat presies is wat die kliënt vergelyk. Besluit dan of die profiel vernou moet word of die sertifikaatmodel verander moet word.

Kyk na die rekord, nie net die eerste antwoord nie

Evalueer drie scenario’s en skryf vier feite vir elkeen: normale toegang, een ligging onbeskikbaar, en die ooreengekome herstelgeval. Die vier feite is die oplosser wat gebruik is, die adres wat teruggegee is, die ligging wat dit bedien het, en ’n vars toepassingsresultaat. Daardie rekord skei ’n DNS-keuseprobleem van ’n gateway-probleem, ’n roeteringsprobleem of ’n sessietoestandprobleem. Sonder dit lyk al vier identies vanaf die kliënt.

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

Voer die scenario’s uit vanaf verteenwoordigende toegangsnetwerke eerder as net vanaf die kantoor, want die hele vraag gaan oor watter ingangspunt verskillende kliënte werklik bereik. Een netwerk is ’n steekproef van een.