Geografyske DNS en anycast: de VPN-yngong kontrolearje dy’t jo krije

Geografyske DNS en anycast kieze yngongen neffens ferskillende regels. Kontrolearje hokker resolver it antwurd werjout, en dan oft de sesje in knooppuntwiksel oerlibbet.

In tichtby DNS-antwurd fielt as in oplost probleem oant de ferbining earne oars lânet. Geografyske DNS en anycast besykje beide it paad koarter te meitsjen, en se nimme dy beslissing út ferskillende ynformaasje. Gjin fan beide garandearret dat de gateway dy’t jo berikke berikber is, dat dy de identiteit toant dy’t jo klient ferwachtet, of dat jo sesje in knooppuntwiksel oerlibbet. De kontrôles hjirûnder skiede dy fjouwer fragen.

Kontrolearje waans lokaasje de resolver eins rapportearret

In autoritative tsjinner dy’t in topology-gefoelige fraach beäntwurdet, sjocht normaalwei it adres fan de rekursive resolver dy’t frege hat, net it adres fan de persoan dy’t de namme typt hat. In sintralisearre resolver kin fier fan de kliïnten stean dy’t er tsjinnet, en it antwurd werjout de resolver earder as harren. Dat is gjin defekt; sa hâldt it protokol him, útsein as ekstra ynformaasje jûn wurdt. Spesifikaasje fan EDNS Client Subnet beskriuwt sawol de beheining as de opsjonele remedie.

EDNS Client Subnet kin ynformaasje oer it oarsprongsnetwurk drage as elke dielnimmer it stipe en ynskeakelet. It is opsjoneel, it hat gefolgen foar privacy en caching, en it is gjin tastimming om oan te nimmen dat hokker iepenbiere resolver dan ek in krekte lokaasje fan de brûker rapportearret. Freegje de resolver-operators foardat jo dêrom hinne ûntwerpe.

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

Kontrolearje wat anycast-routing besletten hat

By anycast meitsje ferskate lokaasjes berikberens bekend foar ien tsjinstadres, en it netwurk leveret elke klient by it knooppunt dat syn routing foarkomt. Dy kar wurdt makke troch BGP en it omlizzende belied, net troch ôfstân op in kaart. Topologyske tichtbyens is ek oer it algemien net itselde as bettere hin-en-wer prestaasje, want it paad dat koart liket kin oerbelêste of asymmetrysk wêze. It adres dat jo krigen hawwe seit neat oer hokker knooppunt antwurde.

Befêstigje de tsjinlokaasje fan de tsjinstkant, of út in antwurd dat it neamt, earder as allinnich út it DNS-antwurd. traceroute -n 198.51.100.20 toant it paad dat jo nommen hawwe en neamt noch altyd net de host oan ’e ein dêrfan, dus lês it as in paad en net as in antwurd.

Kontrolearje dat de sesje in knooppuntwiksel oerlibbet

In DNS-fraach is koart en in VPN-sesje is lang, en de twa hawwe folslein ferskillende easken oan steat. Routing kin healwei de sesje ferskowe, en as dat bart, kinne lettere pakketten by in knooppunt oankomme dat jo tunnel nea sjoen hat. Oft dat te oerlibjen is hinget fan de ymplemintaasje ôf: dielde steat, in bewuste werferbining of in dokumintearre mislearring. It adres allinnich leveret dêrfan neat.

Observearje de ferskowing ynstee fan dy oan te nimmen. sudo tcpdump -ni any -c 20 esp toant de bûtenste pakketten wylst it paad feroaret, en in hommelse feroaring yn it adres fan de peer is de ferskowing sels. Definiearje it bedoelde gedrach eksplisyt foar de ymplemintaasje dy’t jo driuwe, en test it dan troch in paadferoaring te twingen. As it ûntwerp sesjereplikaasje ferûnderstelt, neam dan it meganisme en neam de mislearring dy’t it net dekt.

Kontrolearje dat de identiteit noch past

Elk yngongspunt moat de identiteit toane dy’t jo klientprofyl ferwachtet. In sertifikaat dat foar de tsjinstnamme útjûn is wurket oer knooppunten hinne, wylst sertifikaten per knooppunt de klient twinge om eat nijs te akseptearjen, en dêr leare brûkers om troch warskôgingen hinne te klikken. Hâld de ferwachte identiteit en it profyl yn oerienstimming mei it yngongsmodel.

Kontrolearje it fan in klient dy’t in ûngewoan knooppunt berikt hat, want dat is it gefal wêryn’t in sertifikaat per knooppunt sichtber wurdt. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com printset de keatling en de nammen, wat krekt is wat de klient ferliket. Beskiede dan oft it profyl ferline wurde moat of it sertifikaatmodel feroare.

Kontrolearje it record, net allinnich it earste antwurd

Evaluearje trije senario’s en skriuw fjouwer feiten foar elk: normale yngong, ien lokaasje net beskikber en it ôfpakte gefal fan werstel. De fjouwer feiten binne de brûkte resolver, it weromjûn adres, de lokaasje dy’t tsjinne en in farsk applikaasjerisseltaat. Dat record skiedt in DNS-karfraach fan in gateway-probleem, in routingprobleem of in sesjestietprobleem. Sûnder dat sjogge alle fjouwer der fan de klient út itselde út.

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

Run de senario’s fan represintative tagongsnetwurken ynstee fan allinnich fan it kantoar, want de hiele fraach giet oer hokker yngongspunt ferskillende kliïnten eins berikke. Ien netwurk is in stekproef fan ien.

Relatearre artikelen