VPN ilə yalnız bir özəl alt şəbəkəni necə göndərmək olar

Tuneldən bir özəl alt şəbəkə, qalan hər şey isə adi yolunuzla: kiçik bir tələb, amma onu səhv etməyin çox yolu var. Nəticəni həll edən split tunneling adlı işarələmə qutusu deyil, qərarın harada tətbiq olunduğudur: müştərinin öz marşrut cədvəli, serverin göndərdiyi marşrut və ya iki tərəfin danışıqla razılaşdırdığı siyasət. Səhv qatı seçin və ya heç istəmədiyiniz tam tunel alırsınız, ya da qarşı tərəfin qəbul etmədiyi tunelə işarə edən marşrut. Hər hansı konfiqurasiyanı açmazdan əvvəl üç şərtli sınaq işlədirəm, sonra aşağıdakı mexanizmlərdən birini seçirəm.

Dizaynı həll edən üç şərt

Birincisi, şəbəkə sahibindən dəqiq prefiks və maska lazımdır. 10.x şəbəkəsi prefiks deyil; 10.20.0.0/16 prefikstdir. Onun ev LAN-ınızla, Docker körpüsü ilə və ya işlətdiyiniz başqa VPN ilə üst-üstə düşmədiyini təsdiqləyin, çünki üst-üstə düşmə marşrutu qeyri-müəyyən edir və nüvə nəzərdə tutmadığınız yazını seçir.

İkincisi, cavab trafikinə kim cavab verir. Paketi tunelə yönləndirmək onu yalnız VPN serverinə çatdırır. Əgər alt şəbəkə müştəri hovuzunuza geri marşrutu olmayan başqa marşrutlaşdırıcının arxasındadırsa, server trafiki maskalamalıdır, ya da o marşrutlaşdırıcı sizin hovuzunuzu öyrənməlidir. Heç bir müştəri tərəfli marşrut çatışmayan geri yolunu düzəltmir.

Üçüncüsü, tətbiq nöqtəsi. Bəzi müştərilər marşrut quraşdırır, qalanını əməliyyat sistemi edir. Digərləri siyasət üzərində danışıq aparır və şlüzün qəbul etmədiyi siyasət heç tunel yaratmır: paketlər görünən xəta olmadan atılır. Nə isə yazmazdan əvvəl bu ikisindən hansına sahib olduğunuzu müəyyənləşdirin.

WireGuard: AllowedIPs marşrut cədvəlidir

Müştəridə AllowedIPs tunelə girə bilən təyinatları sadalayır və wg-quick hər yazını adi marşruta çevirir. Yəni bu işin müştəri yarısı bir sətirdir.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

İndi serverin həmin müştəri üçün yazısını müqayisə edin. O, serverin müştəriyə nə göndərəcəyini təsvir edir, bu da adətən müştərinin tunel ünvanıdır, özəl alt şəbəkə deyil.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Bu ikisini dəyişmək ən çox gördüyüm səhvdir. 10.20.0.0/16-i serverin peer bölməsinin altına qoymaq bütün alt şəbəkənin həmin müştərinin arxasında olduğunu bildirir, bu da icazə deyil, sayt-sayta iddiasıdır. Heç bir peer-in AllowedIPs-inə uyğun gəlməyən paketlər səssizcə atılır, ona görə səhv yazı tam olaraq firewall problemi kimi görünür.

Marşrutları özünüz idarə edirsinizsə, [Interface] altında Table = off təyin edin və istədiyiniz marşrutu əlavə edin. Onda heç nə avtomatik əlavə olunmur, ona görə marşrut interfeysi qaldıran şeyin içində yer almalıdır.

OpenVPN: marşrutu göndərin, sonra yerinə düşdüyünə əmin olun

Adi serverdə dəyişiklik server konfiqurasiyasında, müştəri hovuzunun yanında bir göstərişdir.

push "route 10.20.0.0 255.255.0.0"

Müştəri qoşulanda onu əlavə edir. Uğursuzluq rejimi o zaman görünür ki, eyni profil həm də redirect-gateway göndərir, ya da kimsə artıq route-nopull əlavə edib: birincisi sessiyanı tam tunelə çevirir, ikincisi isə sizinki daxil bütün göndərilən marşrutları atır.

Tam tunel serverinə qarşı dar davranışa ehtiyacı olan müştəri yalnız istəmədiyi hissələri görməzdən gəlməlidir. OpenVPN 2.4 və sonrakı versiyalarda pull-filter məhz bunun üçündür.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Ünvan ailələrini ayrı saxlayın: göndərilən IPv4 marşrutu IPv6-ya həll olunan daxili xidmət üçün heç nə etmir və həmin xidmət tunel üzərindən uğursuz olur, qalan hər şey isə qaydasında görünür.

Özəl alt şəbəkə VPN serverində deyil, başqa müştərinin arxasındadırsa, serverə bildirilməlidir. client-config-dir vasitəsilə hər müştəri üçün iroute 10.20.0.0 255.255.0.0 olan fayl əlavə edin, üstəgəl uyğun route ki, digər müştərilər yolu öyrənsin. iroute olmadan serverin həmin prefiksi məhz o tuneldən göndərməyə heç bir səbəbi yoxdur.

IPsec: trafik seçiciləri razılaşmalıdır

IPsec-də göndəriləcək marşrut yoxdur. İki tərəf tunelin içində hansı ünvanların olduğunu danışıqla razılaşdırır və razılaşdırılmış seçicilərdən kənar trafik nə şifrələnir, nə də ondan keçirilir. strongSwan müştərisində seçicilər açıqdır.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Şlüz hər iki tərəfdə 0.0.0.0/0 ilə konfiqurasiya olunubsa, IKEv2 daralması adətən uşaq SA-nı iki təklifin kəsişməsinə endirir, bu da istədiyiniz nəticədir. Bəzi şlüzlər isə konfiqurasiya etdikləri seçicilərə uyğun gəlməyən təklifi rədd edir və jurnal o zaman marşrut şikayəti deyil, uğursuz uşaq SA göstərir. Bu baş verəndə dəyişiklik şlüzə aiddir, çünki müştəri marşrutu qarşı tərəfin qəbul etməyəcəyi seçici üçün tunel yarada bilməz.

Windows-da daxili müştəri eyni qərarı iki parametrin arxasında gizlədir. Split tunneling aktiv olmalıdır və prefiks profilə qeydiyyatdan keçirilməlidir.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Prefiksi qeydiyyatdan keçirmək onu yenidən qoşulmadan sonra da saxlayan şeydir, əl ilə əlavə edilmiş marşrut bunu etmir.

Son nöqtəni və DNS-i qərardan kənarda saxlayın

VPN son nöqtəsi tunel olmadan əlçatan qalmalıdır, əks halda tunel öz içində çökür. Yalnız 10.20.0.0/16 marşrutlaşdırılanda bu avtomatikdir, çünki son nöqtə açıq ünvandır. Tam tunel profilində belə deyil və müştəriyə tunel qalxmazdan əvvəl son nöqtəyə açıq host marşrutu lazımdır.

DNS marşrut göndərişinin sizin üçün vermədiyi ikinci qərardır. Daxili adlar adətən yalnız özəl şəbəkənin çata bildiyi həlledicidən həll olunur. Server DNS serveri göndərirsə, hər ad ondan keçir; göndərmirsə, daxili adlar ya uğursuz olur, ya da nəzərdə tutmadığınız bir şeyə açıq şəkildə həll olunur. Bölünmüş DNS daxili həlledicidə bir axtarış domeni saxlayır, amma bu müştəri dəstəyindən asılıdır, ona görə onu marşrutlaşdırmanın yan təsiri deyil, ayrıca iş kimi qəbul edin.

Yoxlayın, sonra yenidən başladın və yenidən yoxlayın

Üç sınaq marşrut məsələsini əhatə edir. Nüvədən soruşun ki, uzaq ünvan hara gedəcək, alt şəbəkənin içindən nəsə götürün, sonra adi açıq sorğunun hələ də normal bağlantınızdan çıxdığını təsdiqləyin.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Birinci sətir interfeys adlandırır. Fiziki interfeysinizi adlandırırsa, marşrut heç vaxt yerinə düşməyib. Windows-da Find-NetRoute -RemoteIPAddress 10.20.5.7 eyni suala cavab verir və son sınaq hələ də VPN serverinin deyil, adi ünvanınızı göstərməlidir.

Sonra yenidən başladın. Əl ilə əlavə edilən marşrutlar yox olur, profildən, göndərilən konfiqurasiyadan və ya AllowedIPs daxil gələn marşrutlar isə geri qayıdır. Dar giriş yenidən başlatmadan əvvəl işləyib sonra uğursuz olursa, qüsur marşrutun özündə deyil, tunelin necə qalxmasındadır.

Bitmiş saymazdan əvvəl dörd şeyi təsdiqləyin: prefiks şəbəkə sahibindən gəlib və yerli heç nə ilə üst-üstə düşmür, geri yol mövcuddur və ya maskalama qaydası onu əvəz edir, konfiqurasiya etdiyiniz mexanizm platformanızda marşrutlaşdırmanı tətbiq edən mexanizmdir və eyni sınaqlar təmiz yenidən başlatmadan sonra da keçir. strongSwan yönləndirmə qeydləri geri yol daim uğursuz olan hissədirsə, oxumağa dəyər.