Geografinis DNS ir anycast: gaunamo VPN įėjimo patikra

Netoliese esantis DNS atsakymas atrodo kaip išspręsta problema, kol ryšys nusileidžia kitur. Geografinis DNS ir anycast abu bando sutrumpinti kelią, ir šį sprendimą priima iš skirtingos informacijos. Nė vienas negarantuoja, kad pasiekta tinklo sąsaja yra pasiekiama, kad ji pateikia tapatybę, kurios tikisi jūsų klientas, ar kad jūsų sesija išgyvena mazgo pasikeitimą. Toliau pateiktos patikros atskiria šiuos keturis klausimus.

Patikrinkite, kieno vietą sprendėjas iš tikrųjų praneša

Autoritetingas serveris, atsakantis į topologijai jautrų užklausą, paprastai mato rekursyvaus sprendėjo, kuris klausė, adresą, o ne asmens, kuris įvedė vardą, adresą. Centralizuotas sprendėjas gali būti toli nuo klientų, kuriems tarnauja, ir atsakymas atspindi sprendėją, o ne juos. Tai nėra defektas; taip protokolas elgiasi, nebent pateikiama papildoma informacija. EDNS kliento potinklio specifikacija aprašo ir apribojimą, ir pasirenkamą sprendimą.

EDNS kliento potinklis gali perduoti kilmės tinklo informaciją, kai kiekvienas dalyvis jį palaiko ir įjungia. Jis pasirenkamas, turi pasekmių privatumui ir podėliui, ir tai nėra leidimas manyti, kad bet kuris viešas sprendėjas praneša tikslią naudotojo vietą. Klauskite sprendėjų operatorių prieš projektuodami pagal tai.

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

Patikrinkite, ką nusprendė anycast maršrutizavimas

Naudojant anycast, keli taškai skelbia vieno paslaugos adreso pasiekiamumą, o tinklas kiekvieną klientą pristato tam mazgui, kuriam jo maršrutizavimas teikia pirmenybę. Šį pasirinkimą daro BGP ir aplinkinė politika, o ne atstumas žemėlapyje. Topologinis artumas taip pat paprastai nereiškia geresnio našumo pirmyn ir atgal, nes kelias, kuris atrodo trumpas, gali būti perkrautas arba asimetriškas. Gautas adresas nieko nesako apie tai, kuris mazgas atsakė.

Patvirtinkite paslaugos teikimo vietą iš paslaugos pusės arba iš atsakymo, kuriame ji įvardyta, o ne vien iš DNS atsakymo. traceroute -n 198.51.100.20 rodo nueitą kelią ir vis tiek neįvardija prieglobos jo pabaigoje, todėl skaitykite jį kaip kelią, o ne kaip atsakymą.

Patikrinkite, ar sesija išgyvena mazgo pasikeitimą

DNS užklausa yra trumpa, o VPN sesija ilga, ir jų būsenos reikalavimai visiškai skirtingi. Maršrutizavimas gali pasistumti sesijos viduryje, ir kai taip nutinka, vėlesni paketai gali atkeliauti į mazgą, kuris niekada nematė jūsų tunelio. Ar tai ištveriama, priklauso nuo įgyvendinimo: bendra būsena, tyčinis persijungimas arba dokumentuota klaida. Vien adresas nė vieno to nesuteikia.

Stebėkite poslinkį, o ne darykite prielaidą. sudo tcpdump -ni any -c 20 esp rodo išorinius paketus keliui kintant, ir staigus partnerio adreso pasikeitimas yra pats poslinkis. Aiškiai apibrėžkite numatomą elgesį jūsų vykdomam įgyvendinimui, paskui išbandykite jį priversdami kelio pasikeitimą. Jei projektas daro prielaidą apie sesijos replikaciją, įvardykite mechanizmą ir įvardykite gedimą, kurio jis neapima.

Patikrinkite, ar tapatybė vis dar atitinka

Kiekvienas įėjimo taškas turi pateikti tapatybę, kurios tikisi jūsų kliento profilis. Paslaugos vardui išduotas sertifikatas veikia visuose mazguose, o sertifikatai kiekvienam mazgui verčia klientą priimti kažką naujo, ir būtent ten naudotojai išmoksta spragsėti pro įspėjimus. Laikykite tikėtiną tapatybę ir profilį suderintus su įėjimo modeliu.

Patikrinkite tai iš kliento, kuris pasiekė neįprastą mazgą, nes tai atvejis, kai sertifikatas kiekvienam mazgui tampa matomas. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com atspausdina grandinę ir vardus, ir būtent tai klientas lygina. Tada nuspręskite, ar profilį reikia susiaurinti, ar keisti sertifikato modelį.

Patikrinkite įrašą, o ne tik pirmą atsakymą

Įvertinkite tris scenarijus ir kiekvienam užrašykite keturis faktus: įprastas įėjimas, viena nepasiekiama vieta ir sutartas atkūrimo atvejis. Tie keturi faktai yra naudotas sprendėjas, grąžintas adresas, aptarnavusi vieta ir naujas programos rezultatas. Šis įrašas atskiria DNS pasirinkimo problemą nuo tinklo sąsajos, maršrutizavimo ar sesijos būsenos problemos. Be jo visi keturi iš kliento pusės atrodo vienodai.

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

Vykdykite scenarijus iš reprezentatyvių prieigos tinklų, o ne tik iš biuro, nes visas klausimas yra apie tai, kurį įėjimą skirtingi klientai iš tikrųjų pasiekia. Vienas tinklas yra vieno imtis.