Geografski DNS i anycast: provjera VPN ulazne točke koju dobijete

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 iz različitih podataka. Nijedan ne jamči da je pristupnik do kojeg stignete dostupan, da predstavlja identitet koji vaš klijent očekuje, ili da vaša sesija preživljava promjenu čvora. Provjere u nastavku razdvajaju ta četiri pitanja.

Provjerite čiju lokaciju razrješivač zapravo prijavljuje

Autoritativni poslužitelj koji odgovara na upit osjetljiv na topologiju obično vidi adresu rekurzivnog razrješivača koji je pitao, a ne adresu osobe koja je upisala ime. Centralizirani razrješivač može stajati daleko od klijenata kojima služi, a odgovor odražava razrješivač, a ne njih. To nije nedostatak; tako se protokol ponaša osim ako se ne dostave dodatni podaci. Specifikacija EDNS klijentske podmreže opisuje i ograničenje i neobavezni lijek.

EDNS klijentska podmreža može nositi podatke o izvornoj mreži kada je svaki sudionik podržava i omogući. Neobavezna je, ima posljedice za privatnost i keširanje i nije dopuštenje da se pretpostavi da bilo koji javni razrješivač prijavljuje točnu lokaciju korisnika. Pitajte operatere razrješivača prije nego što na tome gradite.

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 usmjeravanje

Uz anycast, nekoliko lokacija oglašava dostupnost za jednu adresu usluge, a mreža dostavlja svakog klijenta do onog čvora koji njegovo usmjeravanje preferira. Tu odluku donose BGP i okolna politika, a ne udaljenost na karti. Topološka blizina također općenito ne znači bolju povratnu izvedbu, jer put koji izgleda kratak može biti zagušen ili asimetričan. Adresa koju ste dobili ne govori ništa o tome koji je čvor odgovorio.

Potvrdite lokaciju posluživanja 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 još uvijek ne imenuje host na njegovom kraju, pa ga čitajte kao put, a ne kao odgovor.

Provjerite da sesija preživljava promjenu čvora

DNS upit je kratak, a VPN sesija duga, i njihovi su zahtjevi za stanje potpuno različiti. Usmjeravanje se može pomaknuti 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 ovisi o implementaciji: dijeljeno stanje, namjerno ponovno povezivanje ili dokumentirani neuspjeh. Sama adresa ne daje ništa od toga.

Promatrajte pomak umjesto da ga pretpostavljate. sudo tcpdump -ni any -c 20 esp prikazuje vanjske pakete kako se put mijenja, a iznenadna promjena adrese partnera je sam pomak. Eksplicitno definirajte namjeravano ponašanje za implementaciju koju pokrećete, zatim ga testirajte forsiranjem promjene puta. Ako dizajn pretpostavlja replikaciju sesije, imenujte mehanizam i imenujte neuspjeh koji ne pokriva.

Provjerite da se identitet još uvijek podudara

Svaka ulazna točka mora predstavljati identitet koji vaš klijentski profil očekuje. Certifikat izdan za ime usluge radi na svim čvorovima, dok certifikati po čvoru prisiljavaju klijenta da prihvati nešto novo, i tu korisnici uče kliktati kroz upozorenja. Držite očekivani identitet i profil usklađene s modelom ulaza.

Provjerite to s klijenta koji je stigao do neobičnog čvora, 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 upravo ono što klijent uspoređuje. Zatim odlučite treba li profil suziti ili promijeniti model certifikata.

Provjerite zapis, a 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 razrješivač, vraćena adresa, lokacija koja je poslužila i svjež rezultat aplikacije. Taj zapis odvaja problem DNS odabira od problema pristupnika, problema usmjeravanja ili problema stanja sesije. Bez njega sva četiri izgledaju identično s klijentske strane.

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

Pokrenite scenarije s reprezentativnih pristupnih mreža, a ne samo iz ureda, jer se cijelo pitanje vrti oko toga do koje ulazne točke različiti klijenti stvarno dolaze. Jedna mreža je uzorak od jednog.