Tətbiq əsaslı və təyinat əsaslı split tunneling: hansını seçməli

Tətbiq əsaslı və təyinat əsaslı split tunneling eyni iş üçün iki ayar deyil. Biri hansı prosesin paket göndərdiyini soruşur; digəri həmin paketin hara getdiyini soruşur. Birinci sual üçün qurulmuş qayda trafik köməkçi prosesdən gələndə səssizcə uğursuz olur, ikinci üçün qurulmuş qayda isə host adı heç vaxt siyahıya almadığınız ünvana çevrildikdə uğursuz olur. Tələbə uyğun obyekti seçin, sonra bunu iki sınaq paketi ilə sübut edin: biri tuneldən istifadə etməli, biri etməməlidir.

İki qayda müxtəlif qatqılarda işləyir

Tətbiq qaydası şəbəkə qatının üstündə, əməliyyat sisteminin göndərənə verdiyi kimliyə qarşı tətbiq olunur. Android-də bu, paketin arxasındakı UID-dir və VPN xidməti hər UID üzrə trafikin tunelə daxil olub-olmadığını qərar verir. Təyinatla bağlı heç nə soruşulmur, buna görə seçilmiş tətbiq hər yerə çata bilər, digər tətbiq isə daxili şəbəkəyə çata bilməz.

Təyinat qaydası paketin özünə tətbiq olunur. Tunel interfeysi bir sıra prefikslərə sahibdir, marşrut cədvəli uyğun trafiki ora göndərir və göndərən prosesin əhəmiyyəti yoxdur. Buna görə təyinat qaydası heç kimin siyahıya salmağı xatırlamadığı xidməti, printeri və ya toplu işi əhatə edir və buna görə müştərisi prosesə heç baxmayan platformada onu yalnız bu proqram kimi ifadə etmək mümkün deyil.

Tətbiq qaydaları mobil müştərilərə və idarə olunan agentlərə uyğundur

Android seçimi birbaşa təqdim edir: VpnService.Builder.addAllowedApplication() və addDisallowedApplication() paket adlarını götürür və qərarı UID üzrə tətbiq edir, bu Android-in VPN tərtibatçı bələdçisində təsvir olunub. iOS-da ekvivalent paket identifikatorlarına bağlanmış hər tətbiq üzrə VPN qaydaları ilə mövcuddur və adətən əl ilə yazılmaq əvəzinə MDM profili ilə verilir.

Masaüstü müştərilər zəif nöqtədir. Windows və macOS VPN müştərilərinin çoxu təyinata görə marşrutlaşdırır və heç bir proses seçicisi təklif etmir, çünki tunel sürücüsü prosesləri deyil, paketləri görür. Planınız noutbukda bir tətbiqi tuneldən keçirməkdən asılıdırsa, bunun ətrafında dizayn qurmazdan əvvəl müştərinin real imkanlarını yoxlayın; bəlkə təyinat siyahısı ilə ikinci maşın arasında seçim edirsiniz.

İnsanların qaçırdığı nəticə: o platformalarda tətbiq qaydasını marşrutlarla təqlid edə bilməzsiniz. Tətbiqin serveri üçün host marşrutu əlavə etmək hər kəsin trafikini o serverə tuneldən keçirir, brauzer və yeniləyici də daxil.

Təyinat qaydaları alt şəbəkə siyahılarına və sayt əlçatanlığına uyğundur

WireGuard modeli açıq edir. AllowedIPs kriptoaçar marşrutlaşdırmasıdır: təyinatı peer siyahısının içində olan daxili paket həmin peer-ə şifrələnir, qalan hər şey normal yolla şifrələnmədən çıxır. Adlandırılacaq proses və nəyin daxil olduğuna dair qeyri-müəyyənlik yoxdur.

OpenVPN itələnən marşrut cədvəli ilə eyni yerə çatır. route-nopull serverin marşrutları diktə etməsini dayandırır, bundan sonra müştəri tərəfindəki route 10.20.0.0 255.255.0.0 vpn_gateway tam ofis prefiksini əhatə edir. IPv6 bu müştərilərin hər birində ayrı bəyanatdır və onu unutmaq düzgün görünən IPv4 bölgüsündən kənara sızmağın ən geniş yayılmış yoludur.

Host adı marşrut deyil. Profil domen sahəsi təklif edirsə, ona müştərinin bir dəfə həll etdiyi ad kimi baxın, daimi ünvan diapazonu kimi yox; məzmun çatdırılma şəbəkələri və yük balanslaşdırıcıları sabah fərqli ünvanlar verəcək.

Hər iki modelin qırıldığı yerlər: köməkçilər, ortaq xidmətlər, həlledicilər

Köməkçi proseslər tətbiq qaydalarını pozur və bu server nasazlığı kimi görünür. Brauzerin yeniləyicisi, qəza hesabatçısı, SYSTEM kimi işləyən sinxronizasiya xidməti və başqa paketə yerləşdirilmiş WebView ayrı-ayrı kimliklərdir, buna görə brauzeri tuneldən keçirmək faktiki sorğunu tuneldən kənarda qoya bilər. Əksi də eyni dərəcədə çaşqındır: tuneldən keçirilən prosesin içindəki paylaşılan kitabxananı çağıran istisna edilmiş tətbiqin trafiki yenə tuneldən keçir.

Təyinat qaydaları ortaq xidmətlərdə və adlarda pozulur. Fayl paylaşımları, printerlər, daxili DNS və lisenziya serveri ünvanlarda yaşayır, buna görə bir tətbiqlik tunel brauzerə giriş verir, map edilmiş disk isə ölü qalır. Bu əhatə fərqi heç bir modeldə səhv deyil, amma bir tətbiqlik tunelin niyə tez-tez VPN işləyir, paylaşım yox oldu nəticəsini verdiyinin səbəbidir.

Həlledicilər hər ikisini kəsir. Müştəri daxili DNS serverləri qurur, lakin əməliyyat sistemi ictimai həllediciyə HTTPS üzərindən DNS istifadə edirsə, cavab tuneldən kənardan gəlir və təyinat qaydası heç vaxt uyğun gəlməyə bilər. Qaydanın səhv olduğu qənaətinə gəlməzdən əvvəl hansı həlledicinin cavab verdiyini yoxlayın və müştəri tərəfində tunel həlledicisinin ümumiyyətlə quraşdırılıb-qurulmadığını təsdiqləyin. DNS-i tuneldən kənarda qoyan bölgü marşrut cədvəlində mükəmməl görünür və yenə də hər daxili adda uğursuz olur.

Əməliyyat planı: seç, tətbiq et, yoxla

Menyudan deyil, tələbdən başlayın. Məqsəd yalnız bu tətbiq tuneldən istifadə etsin olarsa, tətbiq qaydaları və onları dəstəkləyən platforma lazımdır. Məqsəd bu şəbəkələrə tuneldən çatmaq olsa, prefikslər lazımdır. Cavab hər ikisi olarsa, onları iki ayrı idarəedici kimi tətbiq edin və hansının hansı nasazlığa aid olduğunu yazın.

İfadə edə bildiyiniz ən dar formanı tətbiq edin, sonra müştərinin status nişanına deyil, marşrut cədvəlinə soruşaraq yoxlayın:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

İlk iki sətir real təyinatın istifadə edəcəyi interfeysi adlandırır; wg show konfiqurasiya edilmiş prefiks siyahısını çap edir; Windows-da Find-NetRoute paket göndəriləndə stekin cavab verəcəyi eyni suala cavab verir. İnterfeys tuneldirsə, qayda uyğun gəlib.

Sonra istisna edilməli ikinci paketi başqa tətbiqdən eyni təyinata göndərin. Bilettə müştəri versiyasını, qayda növünü, prefiks və ya paket siyahısını və iki müşahidə olunan nəticəni qeyd edin. Məhz bu nəticə cütü növbəti mühəndisə siyasətin səhv konfiqurasiya edildiyini, yoxsa trafikin heç ona aid olmadığını deyir.