Ģeogrāfiskais DNS un anycast: saņemtās VPN ieejas pārbaude

Tuva DNS atbilde šķiet atrisināta problēma, līdz savienojums nolaižas citur. Ģeogrāfiskais DNS un anycast abi cenšas saīsināt ceļu, un šo lēmumu pieņem no atšķirīgas informācijas. Neviens negarantē, ka sasniegtā vārteja ir sasniedzama, ka tā uzrāda identitāti, kuru gaida jūsu klients, vai ka jūsu sesija pārdzīvo mezgla maiņu. Zemāk esošās pārbaudes atdala šos četrus jautājumus.

Pārbaudiet, kura atrašanās vietu risinātājs faktiski ziņo

Autoritatīvs serveris, kas atbild uz topoloģijai jutīgu vaicājumu, parasti redz tā rekursīvā risinātāja adresi, kurš jautāja, nevis tās personas adresi, kura ierakstīja vārdu. Centralizēts risinātājs var atrasties tālu no klientiem, kurus tas apkalpo, un atbilde atspoguļo risinātāju, nevis viņus. Tas nav defekts; tā protokols uzvedas, ja vien netiek sniegta papildu informācija. EDNS klienta apakštīkla specifikācija apraksta gan ierobežojumu, gan neobligāto risinājumu.

EDNS klienta apakštīkls var pārnēsāt izcelsmes tīkla informāciju, ja katrs dalībnieks to atbalsta un iespējo. Tas ir neobligāts, tam ir sekas uz privātumu un kešatmiņu, un tas nav atļauja pieņemt, ka jebkurš publisks risinātājs ziņo precīzu lietotāja atrašanās vietu. Jautājiet risinātāju operatoriem, pirms projektējat uz tā.

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

Pārbaudiet, ko nolēma anycast maršrutēšana

Ar anycast vairākas vietas izsludina vienas pakalpojuma adreses sasniedzamību, un tīkls piegādā katru klientu tam mezglam, kuram dod priekšroku viņa maršrutēšana. Šo izvēli veic BGP un apkārtējā politika, nevis attālums kartē. Arī topoloģiskais tuvums parasti nenozīmē labāku veiktspēju turp un atpakaļ, jo ceļš, kas izskatās īss, var būt pārslogots vai asimetrisks. Saņemtā adrese neko nepasaka par to, kurš mezgls atbildēja.

Apstipriniet apkalpošanas vietu no pakalpojuma puses vai no atbildes, kas to nosauc, nevis tikai no DNS atbildes. traceroute -n 198.51.100.20 parāda jūsu veikto ceļu un joprojām nenosauc resursdatoru tā galā, tāpēc lasiet to kā ceļu, nevis kā atbildi.

Pārbaudiet, vai sesija pārdzīvo mezgla maiņu

DNS vaicājums ir īss un VPN sesija ir gara, un abiem ir pilnīgi atšķirīgas stāvokļa prasības. Maršrutēšana var pavirzīties sesijas vidū, un, kad tas notiek, vēlāki paketes var nonākt mezglā, kas nekad nav redzējis jūsu tuneli. Vai tas ir pārcietams, atkarīgs no ieviešanas: koplietots stāvoklis, apzināta atkārtota savienošana vai dokumentēta kļūme. Tikai adrese neko no tā nesniedz.

Novērojiet pārvietošanos, nevis pieņemiet to. sudo tcpdump -ni any -c 20 esp parāda ārējās paketes, ceļam mainoties, un pēkšņa izmaiņa partnera adresē ir pati pārvietošanās. Skaidri definējiet iecerēto uzvedību ieviešanai, kuru darbināt, un pēc tam pārbaudiet to, piespiežot ceļa maiņu. Ja dizains pieņem sesijas replicēšanu, nosauciet mehānismu un nosauciet kļūmi, kuru tas neaptver.

Pārbaudiet, vai identitāte joprojām atbilst

Katrai ieejai ir jāuzrāda identitāte, kuru gaida jūsu klienta profils. Pakalpojuma vārdam izsniegts sertifikāts darbojas visos mezglos, savukārt sertifikāti katram mezglam liek klientam pieņemt ko jaunu, un tieši tur lietotāji iemācās izklikšķēt brīdinājumus. Saglabājiet gaidīto identitāti un profilu saskaņā ar ieejas modeli.

Pārbaudiet to no klienta, kas sasniedzis neparastu mezglu, jo tas ir gadījums, kad sertifikāts katram mezglam kļūst redzams. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com izdrukā ķēdi un nosaukumus, un tieši to klients salīdzina. Pēc tam izlemiet, vai profils jāsašaurina vai jāmaina sertifikāta modelis.

Pārbaudiet ierakstu, ne tikai pirmo atbildi

Novērtējiet trīs scenārijus un katram pierakstiet četrus faktus: parasta ieeja, viena nepieejama vieta un saskaņotais atjaunošanas gadījums. Četri fakti ir izmantotais risinātājs, atgrieztā adrese, apkalpotā vieta un svaigs lietojumprogrammas rezultāts. Šis ieraksts atdala DNS izvēles problēmu no vārtejas, maršrutēšanas vai sesijas stāvokļa problēmas. Bez tā visi četri no klienta puses izskatās vienādi.

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

Izpildiet scenārijus no reprezentatīviem piekļuves tīkliem, ne tikai no biroja, jo viss jautājums ir par to, kuru ieeju dažādi klienti faktiski sasniedz. Viens tīkls ir viena paraugs.