Domen əsaslı VPN marşrutlaşdırması IP marşrutlarına qarşı: hansı uyğundur?
Split-tunnel qutusundakı host adı marşrut deyil. Domen qaydalarını və açıq prefiksləri yenilənmə, subdomen əhatəsi və DNS dəyişdikdə nə olduğu baxımından müqayisə edin.
IP marşrutu ünvan prefiksi ilə uyğunlaşır və nüvə onu əlavə sual vermədən tətbiq edir. Domen əsaslı VPN qaydası adla uyğunlaşır, yəni yığındakı nə isə həmin adın hazırda hansı ünvanları ifadə etdiyinə qərar verməli və bu qərarı aktual saxlamalıdır. Bunlar fərqli nasazlıq rejimləri olan fərqli mexanizmlərdir və satıcılar hər ikisi üçün eyni sözü işlədir. Onları funksiya siyahılarında müqayisə etmək məğzi qaçırır; cavab dəyişəndə nə baş verdiyinə görə müqayisə edin.
Faydalı bölgü həll edən qayda ilə etməyən qayda arasındadır.
Hər qayda əslində nə ilə uyğunlaşır
Prefiks qaydası marşrut cədvəlindəki təyinat ünvanları ilə uyğunlaşır. Heç nə həll olunmur, heç nə bitmir və uyğunluq hər paket üçün dəqiqdir. Domen qaydası tətbiqin ad sorğusu ilə uyğunlaşır, bunu isə RFC 1034 ünvan deyil, etiketlər ağacı kimi təyin edir. Bəzi məhsullar adı bir dəfə həll edib nəticədə çıxan ünvanları marşrut kimi quraşdırır, bu da qaydayı yeniləmə taymeri əlavə olunmuş IP qaydasına çevirir.
Sazlamağa başlamazdan əvvəl bunlardan hansına sahib olduğunuzu bilin, çünki nasazlıq hər halda tamamilə fərqli görünür.
Domen qaydası yığında harada yerləşir
Məhsul domen qaydalarını yerli proksi vasitəsilə həyata keçirirsə, trafik həmin proksiyə çatmalıdır və sistem proksisini nəzərə almayan tətbiqlər qaydayı tamamilə yan keçir. Əgər onları adları həll edib marşrutlar əlavə etməklə həyata keçirirsə, ünvanlar yalnız son yenilənmə qədər təzədir. Əgər həlledicini qoşursa, DNS davranışı marşrutlaşdırma siyasətinin bir hissəsinə çevrilir və ehtiyat həlledici onu səssizcə ləğv edə bilər.
Parametrlərin etiketini deyil, satıcının modelini oxuyun. Split Tunnel adlı qutusu olan iki müştəri üç fərqli iş görə bilər.
Nəyin pozulduğunu müqayisə edin
Üç şey fərqli pozulur. Ünvan dəyişməsi: CDN host adı bir neçə dəqiqə ərzində fərqli ünvan çoxluğuna həll oluna bilər, ona görə kopyalanmış siyahı tez köhnəlir. Subdomen əhatəsi: example.com üçün qayda api.example.com-u əhatə edə bilər və ya etməyə bilər, sənədləşmə isə adətən hansının olduğunu açıq deyir. Həll uğursuzluğu: həlledici sıradan çıxanda həll edən müştəri trafiki tunelləməyə və ya birbaşa göndərməyə keçə bilər.
Yalnız ikincisi konfiqurasiya sualıdır. Digər ikisi məhsulun nə qədər təxmin etməyə hazır olduğuna dair dizayn suallarıdır.
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
Prefiksin daha yaxşı cavab olduğu hal
Sabit şəxsi alt şəbəkə üçün açıq prefiks daha aydın, daha sürətli və audit etmək daha asandır. O, həlledicinin nasazlığına da dözür, çünki heç nə həll olunmalı deyil. Domen qaydasına xidmət hostinqdə olduqda, ünvanlar fırlandıqda və ya təyinat çoxluğunu həqiqətən sadalaya bilmədikdə müraciət edin. Yalnız host adının təsadüfən bildiyiniz şey olduğuna görə ona müraciət etməyin.
Təxmin edilmiş statik siyahı hər ikisinin ən pisi: qayğı görünür və provayder host əlavə etdiyi gün trafiki səssizcə qaçırır.
Təzə sorğu ilə yoxlayın
Normal yenidən qoşulmadan sonra soyuq sorğu ilə sınaqdan keçirin, çünki keşlənmiş səhifə qaydaya heç vaxt toxunmaya bilər. Adı həll edin, sonra bağlantının əslində hara getdiyini yoxlayın. dig +short app.example.com cari ünvan çoxluğunu verir və müştərinin bağlantı siyahısı axını hansı interfeysin daşıdığını göstərir.
Məhsulun sənədləşdirdiyi yenilənmə intervalından sonra təkrarlayın. Ünvan çoxluğu sürüşsə və qayda onu izləmirsə, həqiqi davranışı tapmışsınız.
Həlledici siyasətini də ayrı saxlayın. Domen qaydası düzgün ad məlumatına ehtiyac duyur, lakin sorğuya hansı həlledicinin cavab verəcəyini təkbaşına həll etmir.