Geografski DNS i anycast: provjera VPN ulazne tačke koju dobijate

Obližnji DNS odgovor izgleda kao riješen problem sve dok veza ne sleti negdje drugdje. Geografski DNS i anycast oba pokušavaju skratiti put i tu odluku donose na osnovu različitih informacija. Nijedan ne garantuje da je pristupna tačka do koje stižete dostupna, da predstavlja identitet koji vaš klijent očekuje ili da vaša sesija preživljava promjenu čvora. Provjere ispod razdvajaju ta četiri pitanja.

Provjerite čiju lokaciju resolver zapravo prijavljuje

Autoritativni server koji odgovara na upit osjetljiv na topologiju obično vidi adresu rekurzivnog resolvera koji je pitao, a ne adresu osobe koja je otkucala ime. Centralizovani resolver može stajati daleko od klijenata kojima služi, a odgovor odražava resolver, a ne njih. To nije defekt; tako se protokol ponaša osim ako se ne dostave dodatne informacije. Specifikacija EDNS Client Subnet opisuje i ograničenje i opcionalno rješenje.

EDNS Client Subnet može nositi informacije o izvornoj mreži kada svaki učesnik to podržava i uključi. Opcionalan je, ima posljedice po privatnost i keširanje i nije dozvola da se pretpostavi da bilo koji javni resolver prijavljuje tačnu lokaciju korisnika. Pitajte operatere resolvera prije nego što dizajnirate na osnovu toga.

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

Provjerite šta je odlučilo anycast rutiranje

Uz anycast, nekoliko lokacija oglašava dostupnost jedne adrese usluge, a mreža dostavlja svakog klijenta onom čvoru koji njegovo rutiranje preferira. Tu odluku donose BGP i okolna politika, a ne udaljenost na mapi. Topološka blizina takođe generalno ne znači bolje performanse povratnog puta, jer put koji izgleda kratko može biti zagušen ili asimetričan. Adresa koju ste dobili ne govori ništa o tome koji je čvor odgovorio.

Potvrdite lokaciju koja uslužuje sa strane usluge ili iz odgovora koji je imenuje, a ne samo iz DNS odgovora. traceroute -n 198.51.100.20 prikazuje put kojim ste išli i dalje ne imenuje host na njegovom kraju, pa ga čitajte kao put, a ne kao odgovor.

Provjerite da li sesija preživljava promjenu čvora

DNS upit je kratak, a VPN sesija duga, i oba imaju potpuno različite zahtjeve za stanjem. Rutiranje se može pomjeriti usred sesije, a kada se to dogodi, kasniji paketi mogu stići na čvor koji nikada nije vidio vaš tunel. Da li je to preživljivo zavisi od implementacije: dijeljeno stanje, namjerno ponovno povezivanje ili dokumentovani kvar. Sama adresa ne pruža nijedno od toga.

Posmatrajte pomak umjesto da ga pretpostavljate. sudo tcpdump -ni any -c 20 esp prikazuje vanjske pakete dok se put mijenja, a nagla promjena adrese partnera je pomak koji se dešava. Eksplicitno definišite namjeravano ponašanje za implementaciju koju pokrećete, a zatim je testirajte prisiljavanjem promjene puta. Ako dizajn pretpostavlja replikaciju sesije, imenujte mehanizam i imenujte kvar koji ne pokriva.

Provjerite da li se identitet još uvijek poklapa

Svaka ulazna tačka mora predstaviti identitet koji vaš klijentski profil očekuje. Certifikat izdat za ime usluge radi preko čvorova, dok certifikati po čvoru prisiljavaju klijenta da prihvati nešto novo, i tu korisnici uče da klikću kroz upozorenja. Držite očekivani identitet i profil usklađene s modelom ulaza.

Provjerite to s klijenta koji je stigao na neobičan čvor, jer to je slučaj u kojem certifikat po čvoru postaje vidljiv. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com ispisuje lanac i imena, što je tačno ono što klijent poredi. Zatim odlučite da li profil treba suziti ili model certifikata promijeniti.

Provjerite zapis, ne samo prvi odgovor

Procijenite tri scenarija i zapišite četiri činjenice za svaki: normalan ulaz, jedna lokacija nedostupna i dogovoreni slučaj oporavka. Četiri činjenice su korišteni resolver, vraćena adresa, lokacija koja je uslužila i svjež rezultat aplikacije. Taj zapis razdvaja problem DNS izbora od problema ulazne tačke, problema rutiranja ili problema stanja sesije. Bez njega, sva četiri izgledaju identično s klijenta.

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

Pokrećite scenarije iz reprezentativnih pristupnih mreža, a ne samo iz ureda, jer cijelo pitanje je do koje ulazne tačke različiti klijenti zaista stižu. Jedna mreža je uzorak od jedne.