Bir IPv4 hədəfini OpenVPN tunelindən kənara necə göndərmək olar

Əksər tam tunel qurğuları hər paketi VPN-dən keçirir və redirect-gateway bunu təmin edən direktivdir. Tək bir təyinat yenə də istisna edilə bilər. Həmin ünvan üçün net_gateway yer tutucusu ilə host marşrutu əlavə etmək müştəriyə onu maşının ilkin şlüzü vasitəsilə almağı tapşırır, qalan hər şey isə tuneldən istifadə etməyə davam edir.

Sətir zərərsiz görünür və çox vaxt elədir, lakin o, yalnız bir sualı həll edir: həmin dəqiq IPv4 ünvanına gedən paketlər hara gedir. O, DNS-i, IPv6-nı, firewall siyasətini və ya bağlantını hansı prosesin açdığını dəyişmir və bunların hər biri istisnanı səssizcə poza bilər.

net_gateway əslində nəyi adlandırır

Həmin istisna üçün profil qeydi bir sətirdir: route 198.51.100.77 255.255.255.255 net_gateway. Birinci ünvan təyinat üçün sənədləşdirmə yer tutucusudur, maska onu tək host marşrutuna çevirir və sonuncu token şlüz yer tutucusunu adlandırır. OpenVPN marşrutları quraşdırarkən şlüz yer tutucularını həll edir. vpn_gateway tunelin öz şlüzünü, yəni VPN bağlantısının uzaq tərəfini bildirir. net_gateway VPN hər şeyi dəyişməzdən əvvəl hostun malik olduğu default şlüzü bildirir ki, bu da adətən fiziki şəbəkədəki yerli marşrutlaşdırıcıdır.

Üçüncü yer tutucu, remote_host, VPN serverinin ünvanına işarə edir və tunelin serverə fiziki yol üzərindən çata bilməsi üçün mövcuddur. Bu üçünü qarışdırmaq istisnanın yanlış yerə getməsinin və ya ümumiyyətlə quraşdırılmamasının ən çox yayılmış səbəbidir.

Dəyər qoşulma anında oxunur, fayla yazılmır. Maşın başqa şəbəkəyə keçərsə, VPN-dən əvvəlki şlüz dəyişir və marşrut yenisini izləyir. Bu, adətən istədiyiniz şeydir, lakin o da deməkdir ki, istisnanın davranışı müştərinin başladığı şəbəkədən asılıdır.

Niyə host marşrutu tunelin default marşrutunu üstələyir

Marşrutlaşdırma ən dəqiq uyğun prefiksə görə qərarlaşdırılır. redirect-gateway def1 adətən default marşrutu əvəz etmir; o, iki yarım əlavə edir, ünvan fəzasının aşağı yarısı üçün bir marşrut və yuxarı yarısı üçün bir marşrut, belə ki ilkin default marşrut başqa istifadələr üçün qorunur. Bu yarımlar tək ünvandan daha genişdir.

255.255.255.255 maskası ilə bir ünvan üçün marşrut /32-dir və bu, IPv4-ün çata biləcəyi ən dəqiq həddir. Həmin ünvan üçün paket qiymətləndirildikdə /32 uyğun gəlir və hansı marşrutun əvvəl quraşdırıldığından asılı olmayaraq qalib gəlir. İstisnanın arxasındakı mexanizm budur və marşrut həqiqətən mövcud olduğu müddətcə Linux, macOS və Windows-da eyni cür işləyir.

Windows ikinci ölçü əlavə edir. İki marşrut eyni dərəcədə dəqiq olduqda daha aşağı metrikalı olan qalib gəlir və VPN adapteri nəticəni dəyişən interfeys metrikası daşıya bilər. /32 yenə də yarımlardan daha dəqiqdir, ona görə istisna adətən qüvvədə qalır, lakin əvvəlki sessiyadan qalmış köhnə marşrut eyni dərəcədə dəqiqdirsə, çaşdırıcı nəticə verə bilər.

İstisnanın əhatə etmədikləri

DNS birinci boşluqdur. Müştəri daxili həlledici ayarlarını itələyə bilər və əməliyyat sistemi onları axtarışlar üçün istifadə etməyə davam edəcək. Adı qoşulmadan əvvəl həll edən tətbiq düz getməli olan xidmət üçün daxili ünvan ala bilər və ya düzgün həll olunan, sonra növbəti boşluğa ilişən xarici ünvan ala bilər.

IPv6 ikincidir. Marşrut direktivi yalnız IPv4 ilə işləyir. İkili stek təyinatı IPv6-ya üstünlük verə bilər və o, siyasətdən asılı olaraq tuneli və ya hostun IPv6 default marşrutunu izləyir, belə ki IPv4 istisnası heç vaxt işə düşmür. Uyğun IPv6 marşrutuna və ya həmin müştəri üçün IPv6-nı söndürmək qərarına ehtiyacınız var.

Tətbiq əhatəsi üçüncüdür. Qayda təyinat əsaslıdır, ona görə həmin ünvana qoşulan hər proses birbaşa yoldan istifadə edir, istər nəzərdə tutduğunuz proses olsun, istər olmasın. Əksinə, veb sayt bir neçə ünvandan cavab verə bilər, ona görə bir /32-ni istisna etmək saytı istisna etmir. Əgər əsl tələb hər tətbiq üzrə marşrutlaşdırma olarsa, Community müştərisinin marşrut cədvəli yanlış alətdir.

Özünüzü aldatmadan istisnanı yoxlamaq

Quraşdırılmış marşrutla başlayın, brauzerlə deyil. Linux-da kərneldən konkret ünvan üçün hansı marşrut və növbəti atlamadan istifadə edəcəyini soruşun; Windows-da həmin /32 üçün marşrut cədvəlini oxuyun. Şlüzün tunel deyil, fiziki şlüz olduğunu təsdiqləyin. Əgər qeyd yoxdursa, profil tətbiq olunmayıb və ya müştərinin marşrutları dəyişmək imtiyazı olmayıb.

Sonra iki təyinatı sınayın. İstisna edilmiş ünvana sorğu fiziki interfeysdən çıxmalı, nəzarət daxili ünvana sorğu isə hələ də tuneldən istifadə etməlidir. Yalnız istisna edilmiş ünvanı sınamaq tunelin qalan hissəsi haqqında heç nə sübut etmir və ictimai veb saytı sınamaq həmin saytın həll etdiyi ünvanı sınayır, hansı ki qaydadakı ünvan olmaya bilər.

Nəhayət, marşrutu üstələyə bilən nəzarət vasitələrini yoxlayın. Müştəri tərəfindəki kill switch və ya Windows-un block-outside-dns ayarı birbaşa trafiki qadağan edə bilər və bu, marşrut düzgün olsa da uğursuz olan bağlantı kimi görünür. İstisnanın işlədiyi görünsün deyə həmin nəzarət vasitələrini söndürməyin; əgər siyasət birbaşa yolu qadağan edirsə, istisna VPN xidmətinin sahibi üçün dizayn problemidir.

Yenidən qoşulduqdan və ya şəbəkə dəyişdirdikdən sonra yenidən yoxlayın, çünki VPN-dən əvvəlki şlüz və mövcud yol profilin deyil, anın xassələridir.