Coğrafi DNS və anycast: aldığınız VPN giriş nöqtəsini yoxlamaq

Yaxınlıqdaki DNS cavabı həll olunmuş problem kimi görünür, ta ki bağlantı başqa yerdə düşənə qədər. Coğrafi DNS və anycast ikisi də yolu qısaltmağa çalışır və bu qərarı fərqli məlumatlardan verir. Heç biri çatdığınız şlüzün əlçatan olduğuna, müştərinizin gözlədiyi kimliyi təqdim etdiyinə və ya sessiyanızın düyün dəyişikliyinə dözdüyünə zəmanət vermir. Aşağıdaki yoxlamalar bu dörd sualı ayırır.

Həlledicinin əslində kimin yerini bildirdiyini yoxlayın

Topologiyaya həssas sorğuya cavab verən səlahiyyətli server adətən soruşan rekursiv həlledicinin ünvanını görür, adı yazan adamın ünvanını deyil. Mərkəzləşdirilmiş həlledici xidmət etdiyi müştərilərdən uzaqda ola bilər və cavab onlardan çox həlledicini əks etdirir. Bu qüsur deyil; əlavə məlumat verilmədikcə protokol belə davranır. EDNS Client Subnet spesifikasiyası həm məhdudiyyəti, həm də seçimli düzəlişi təsvir edir.

EDNS Client Subnet hər iştirakçı onu dəstəkləyib aktivləşdirəndə mənşə şəbəkəsi məlumatını daşıya bilər. O, seçimlidir, məxfilik və keş nəticələri var və hər hansı ictimai həlledicinin dəqiq istifadəçi yerini bildirdiyini fərz etmək üçün icazə deyil. Onun ətrafında dizayn qurmazdan əvvəl həlledici operatorlarından soruşun.

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

Anycast marşrutlaşdırmasının nə qərarlaşdırdığını yoxlayın

Anycast ilə bir neçə yer bir xidmət ünvanı üçün əlçatanlıq elan edir və şəbəkə hər müştərini marşrutlaşdırmasının üstün tutduğu düyünə çatdırır. Bu seçimi xəritədəki məsafə deyil, BGP və ətraf siyasət edir. Topoloji yaxınlıq da ümumiyyətlə daha yaxşı gediş-dönüş performansı demək deyil, çünki qısa görünən yol tıxanmış və ya asimmetrik ola bilər. Sizə verilən ünvan hansı düyünün cavab verdiyi barədə heç nə demir.

Xidmət yerini DNS cavabından tək deyil, xidmət tərəfindən və ya onu adlandıran cavabdan təsdiqləyin. traceroute -n 198.51.100.20 getdiyiniz yolu göstərir və yenə də sonundaki hostu adlandırmır, ona görə onu cavab kimi deyil, yol kimi oxuyun.

Sessiyanın düyün dəyişikliyinə dözdüyünü yoxlayın

DNS sorğusu qısadır, VPN sessiyası isə uzundur və ikisinin tamamilə fərqli vəziyyət tələbləri var. Marşrutlaşdırma sessiya ortasında dəyişə bilər və dəyişəndə sonrakı paketlər tunelinizi heç görməmiş düyünə çata bilər. Bunun dözümlü olub-olmaması tətbiqdən asılıdır: paylaşılan vəziyyət, qəsdən yenidən qoşulma və ya sənədləşdirilmiş uğursuzluq. Tək ünvan bunların heç birini təmin etmir.

Dəyişikliyi fərz etmək əvəzinə onu müşahidə edin. sudo tcpdump -ni any -c 20 esp yol dəyişdikcə xarici paketləri göstərir və peer ünvanındaki qəfil dəyişiklik məhz həmin dəyişiklikdir. İşlətdiyiniz tətbiq üçün nəzərdə tutulan davranışı açıq şəkildə müəyyənləşdirin, sonra yolu məcburi dəyişməklə onu sınaqdan keçirin. Əgər dizayn sessiya replikasiyasını fərz edirsə, mexanizmi və əhatə etmədiyi uğursuzluğu adlandırın.

Kimliyin hələ də uyğun olduğunu yoxlayın

Hər giriş nöqtəsi müştəri profilinizin gözlədiyi kimliyi təqdim etməlidir. Xidmət adı üçün verilmiş sertifikat düyünlər arasında işləyir, düyün başına sertifikatlar isə müştərini yeni bir şeyi qəbul etməyə məcbur edir və istifadəçilər xəbərdarlıqları keçməyi məhz burada öyrənir. Gözlənilən kimliyi və profili giriş modeli ilə uyğun saxlayın.

Bunu qeyri-adi düyünə çatmış müştəridən yoxlayın, çünki düyün başına sertifikatın göründüyü hal elə budur. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com zənciri və adları çap edir, müştərinin müqayisə etdiyi də məhz budur. Sonra profilin daraldılmalı və ya sertifikat modelinin dəyişdirilməli olduğuna qərar verin.

Qeydə baxın, təkcə ilk cavaba deyil

Üç ssenarini qiymətləndirin və hər biri üçün dörd fakt yazın: normal giriş, bir yer əlçatmaz, və razılaşdırılmış bərpa halı. Dörd fakt bunlardır: istifadə olunan həlledici, qaytarılan ünvan, xidmət edən yer və təzə tətbiq nəticəsi. Bu qeyd DNS seçimi problemini şlüz probleminindən, marşrutlaşdırma probleminindən və ya sessiya vəziyyəti probleminindən ayırır. O olmadan dördü də müştəri tərəfindən eyni görünür.

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

Ssenariləri yalnız ofisdən deyil, təmsilçi giriş şəbəkələrindən işlədin, çünki bütün sual fərqli müştərilərin həqiqətən hansı giriş nöqtəsinə çatdığı ilə bağlıdır. Bir şəbəkə bir nümunədir.