Bölünmüş tunel: yalnız daxil etmə, yoxsa yalnız xaric etmə — hansı standart seçilməli?
Siyahını qurmazdan əvvəl standartı seçin: yalnız adını çəkdiklərinizi tunelə salın, ya da hər şeyi tunelə salıb istisnaları kənara çıxarın. Sonra heç kimin siyahıya yazmadığı tətbiqi sınaqdan keçirin.
VPN müştərinizin marşrutlaşdırma bölməsini açın və qarşınızda çox vaxt eyni adı daşıyan iki fərqli formalı idarəetmə elementi görəcəksiniz. Biri tunelə aid olan təyinatları sadalamağınızı istəyir, qalan hər şey isə yerli şəbəkədən istifadə etməyə davam edir. Digəri hər şeyin tuneldən keçdiyini fərz edir və nəyin kənara çıxarılmalı olduğunu soruşur. Hər ikisi ilk sınaqda işlək tunel verir və hər ikisi siyahıya sətir əlavə etməklə saxlanılır, fərq məhz buna görə kimsə yeni bir şey quraşdırana qədər görünməz qalır.
Bu seçim bir funksiya deyil, standartdır. Siyahıda iyirmi giriş olmamışdan əvvəl onu həll edin.
Standartı broşüradan deyil, müştəridən oxuyun
WireGuard qərarı qeyri-adi dərəcədə görünən edir, çünki AllowedIPs sadəcə daxiletmə siyahısıdır, başqa heç nə deyil. 0.0.0.0/0, ::/0 olan peer hər şeyi tunelə salır; 10.20.0.0/16 olan peer isə yalnız onu tunelə salır. Xaricetmə sintaksisi yoxdur, ona görə bir subneti kənarda saxlamaq istəsəniz, ya bütün digər prefiksləri sadalamalı, ya da interfeysdən kənarda siyasət marşrutlaşdırması əlavə etməlisiniz.
OpenVPN eyni nəticəyə əks istiqamətdən gəlir: redirect-gateway def1 tam tunel qurur, açıq route direktivləri isə müəyyən prefiksləri əlavə edir və ya üstələyir. Kommersiya müştəriləri adətən hər ikisini bir onay qutusu və təyinat cədvəlinin arxasında gizlədir, ona görə etiketə güvənməzdən əvvəl cədvəlin hansını redaktə etdiyini oxuyun.
Verməli olduğunuz sual onay qutusunun adı deyil. Sual, təyinatı iki siyahının heç birində görünməyən paketin başına nə gəldiyidir. Bunu yazılı şəkildə cavablandırın, konfiqurasiyanın qalanı cavabdan çıxacaq. Sualı keçsəniz, ilk izahsız nasazlığı həmin gün müştəriyə ən yaxın olan şəxs həll edəcək.
Heç kimin siyahıya yazmadığı tətbiqi izləyin
Yalnız daxiletmə dizaynında həmin tətbiq birbaşa, yerli şəbəkədə, yerli DNS ilə gedir. Yalnız xaricetmə dizaynında isə tuneldən keçir və serverin icazə verdiyi hər şeyə tabedir; bu, çox vaxt yeni SaaS alətinin ilk gündən işləməsi ilə VPN-in onu pozduğunu bildirən bileti ayıran fərqdir.
Heç bir standart təkbaşına digərindən daha təhlükəsiz deyil. Yalnız daxiletmə tunelin daşıdığını daraldır və yerli şəbəkəni ən az müqavimət yolu edir; yalnız xaricetmə isə tuneli normal yol fərz edir və istisnalara istisna kimi yanaşır, bu da əksər korporativ siyasətlərin əslində nəzərdə tutduğuna daha yaxındır.
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
Platformanın hansı növ obyekti sadaladığına diqqət edin
Android-də VpnService.Builder icazəli tətbiq siyahısını və icazəsiz tətbiq siyahısını iki ayrı model kimi təqdim edir, hər tətbiq üzrə qaydalar isə təyinatla deyil, paketlə seçim edir. Belə siyahıya düşən brauzer açdığı hər təyinatı daşıyır; bu, marşrut cədvəlindən fərqli bir dəqiqlik səviyyəsidir və işləyən tətbiqin içindəki bir pozulmuş saytı düzəldə bilməz.
Masaüstü müştərilər adətən iki növü bir interfeysdə qarışdırır, ona görə əlavə etdiyiniz sətrin paket, host adı, yoxsa prefiks olduğunu yoxlayın. Onlar fərqli şəkildə nasaz olur və fərqli yerlərdə həll edilir. Host adı sətri adətən marşrut və ad olur, paket sətri isə müştərinin içində siyasət qərarına çevrilir. Hansını əlavə etdiyinizi yazın, çünki sonra onu sazlayan şəxs digərini fərz edəcək.
Yalnız uğurlu yolu deyil, nasazlıq halını da sınayın
Tuneldən xaric edilmiş tətbiq avtomatik olaraq təmiz birbaşa giriş əldə etmir. Müştəri həm də VPN olmadan bloklama qaydası tətbiq edirsə, xaric edilmiş trafik tamamilə atıla bilər; bu, marşrut qərarı kimi deyil, pozulmuş tətbiq kimi görünür. Bu halı istifadəçi hesabatından öyrənmək əvəzinə qəsdən sınayın.
Sonra DNS və IPv6-nı ayrı-ayrı maddələr kimi yoxlayın. Yalnız IPv4 daşıyan tunel v6 qabiliyyətli tətbiqə ondan yan keçən bir yol buraxır, split DNS isə daxili adların heç tuneldən keçməyən trafik üçün həll olunub-olunmadığını müəyyən edir. Siyahıdakı tətbiqi, siyahıda olmayan tətbiqi, bir ad sorğusunu və bir yenidən qoşulmanı işə salın və nəticələri konfiqurasiya ilə birlikdə saxlayın.
Standartı növbəti şəxsin tapacağı yerdə yazın
Seçilmiş standartı, istisnaları və onların kimə aid olduğunu müştəri profilinin saxlandığı yerdə qeyd edin, çünki növbəti administrator bu əsaslandırmanı oxumadan giriş əlavə edəcək. Hər istisna üçün tarixi və səbəbi yazın ki, sonradan düzəldilmiş sayt üçün köhnəlmiş kənarlaşdırma əminliklə silinsin. Səbəbi olmayan siyahı sonsuza qədər böyüyür.
Kimsə bir pozulmuş təyinat barədə məlumat verəndə əsas xətti deyil, istisnanı dəyişin. Tək bir saytı düzəltmək üçün standartı çevirmək, siyahıda olmayan hər tətbiqi səssizcə tunelin o biri tərəfinə keçirir.