Niyə bir subnet hələ də VPN default marşrutunu yan keçir

VPN-i tam tunelə keçirirsiniz, trafikin çoxu itaət edir, sonra bir ünvan birbaşa cavab verir — 10.x-də bir printer, NAS, keçid hostu. Aşkar oxunuş tunelin sızdığıdır, ona görə default marşrutun metriyini aşağı salırsınız və heç nə dəyişmir. Bu uğursuz cəhd işarədir: default marşrut ehtiyat variantdır, hökm deyil. Marşrut axtarışı metrikləri müqayisə etməzdən əvvəl ən uzun uyğun prefiksi götürür, buna görə /24 hər ikisinə hansı rəqəmi bağlasanız da /0-a qalib gəlməyə davam edir. Bu sıra aydın olduqdan sonra sızma adətən kiminsə qəsdən quraşdırdığı marşrut, ya da müştərinin heç vaxt əhatə etmək istəmədiyi prefiksdir.

Default marşrut əslində nə vəd edir

0.0.0.0/0 hər IPv4 təyinatına sıfır bitlik dəqiqliklə uyğun gəlir. O, hostun cədvəlinin daha yaxşı təsvir etmədiyi hər şeyə çata bilməsi üçün mövcuddur. 192.168.1.0/24 marşrutu 24 uyğun bit daşıyır, buna görə 192.168.1.40 üçün hər kəs metrikləri, inzibati məsafəni və ya müştərinin prioritet sahəsi adlandırdığı şeyi müqayisə etməzdən əvvəl qalib gəlir. Eyni qayda Linux FIB-də, Windows marşrut cədvəlində və macOS arxasındakı BSD yığınında qüvvədədir.

Adi lokal şəbəkədə bu davranış bir xüsusiyyətdir. Lokal subnet birbaşa qoşulub, tunel gəzintinizi daşıyarkən printer işləməyə davam edir və heç nə səhv konfiqurasiya edilməyib. Sualmağa dəyər sual o bir ünvanın niyə birbaşa getdiyi deyil, hansı cədvəldə hansı prefiksin ona uyğun gəldiyi və onu ora kimin qoyduğudur.

Yarım-defaultlar, ya da default qeydin niyə toxunulmamış görünə biləcəyi

OpenVPN-in redirect-gateway def1 parametri ən təmiz nümunədir. Default marşrutunuzu silib əvəz etmək əvəzinə, o, 0.0.0.0/1 və 128.0.0.0/1 əlavə edir. Cütlük birlikdə bütün IPv4-ü əhatə edir, hər prefiks /0-dan uzundur və hər ikisi router-in defaultunu yerində saxlayaraq onu üstələyir. Sonra marşrut siyahısını işə salın: orijinal default hələ də oradadır, hələ də gateway-inizə işarə edir; sadəcə internet təyinatları üçün heç vaxt seçilmir.

WireGuard-un wg-quick aləti eyni nəticəyə siyasət əsaslı marşrutlaşdırma ilə çatır. AllowedIPs 0.0.0.0/0-ı əhatə etdikdə öz cədvəlini yaradır, işarələnmiş paketləri ora göndərir və əsas cədvəlin sıfır uzunluqlu prefiksini nəzərə almayan qayda əlavə edir. Əsas cədvəl öz default qeydini saxlayır, qaydalar isə interfeysin sahib olduğu trafik üçün əvvəlcə tunel cədvəlinə baxıldığını müəyyən edir.

Hər iki dizayn tuneldən kənarda dəqiq bir marşrut tələb edir: orijinal gateway vasitəsilə VPN serverinin öz ünvanına host marşrutu. Bu olmadan müştəri tuneli quran paketləri tunelin içində daşımağa çalışardı və bağlantı heç vaxt tamamlanmazdı. Buna görə cədvəlinizdəki tunel olmayan marşrut ciddi tam tunel profilində belə normaldır. Sual verilməyə dəyər marşrutlar əslində əhəmiyyət verdiyiniz təyinatları əhatə edənlərdir.

Metriklər bərabərliyi, prefikslər qalibi həll edir

Metriklər yalnız təyinatı eyni dərəcədə yaxşı uyğunlaşdıran namizədlər arasında müqayisə edilir. Linux-da ip route get 10.20.5.9 qalibi öz cədvəli ilə birlikdə çap edir, və ip route show table all namizədləri, o cümlədən istənilən yarım-default və qaydanın işarə etdiyi istənilən cədvəli sadalayır. Windows-da, Find-NetRoute -RemoteIPAddress 10.20.5.9 seçilmiş marşrutu və mənbə ünvanını qaytarır, halbuki Get-NetRoute xam cədvəli göstərir — lakin effektiv xərc marşrut metriki üstəgəl interfeys metriki olduğundan yavaş adapter qazandığı görünən bərabərliyi itirə bilər.

Görəcəklərinizin çoxunu üç hal əhatə edir:

• Eyni təyinat, /24 - /0: metriklər nə deyirsə desin, /24 prefiks uzunluğuna görə qalib gəlir.
• Eyni təyinat, fərqli metriklərə malik iki /24: daha aşağı effektiv metrik qalib gəlir.
• Eyni təyinat, iki cədvəl, biri siyasət qaydası ilə seçilir: qayda əvvəlcə cədvəli seçir, prefiks müqayisəsi onun içində baş verir.

Üçüncü hal bu hesabatların çoxunun bitdiyi yerdir. Linux-da ip rule və ya Windows VPN trafik filtri trafiki heç vaxt tunel defaultunu saxlamayan cədvələ göndərə bilər, əsas cədvəl isə bütün müddət qüsursuz görünür.

Bu yan keçmənin sahibi adətən kimdir

Cədvəllə deyil, profillə başlayın. Split-tunel konfiqurasiyaları və hər tətbiq üzrə VPN parametrləri adlandırılmış prefiksləri qəsdən tuneldən kənarda saxlayır; bir özəl subeneti qoruyan və ümumi gəzintini birbaşa buraxan iş profili dizayn edildiyi kimi davranır və onu ləğv etmək qurulduğu siyasəti pozur. Microsoft-un VPN marşrutlaşdırma təlimatı məcburi tunel trafiki ilə açıq istisnalar arasında eyni xətti çəkir, bu da hər hansı dəyişiklik etməzdən əvvəl onu faydalı yoxlama edir.

Sonra qalıqları axtarın. Artıq mövcud olmayan interfeysə və ya əvvəlki şəbəkədən olan ünvana işarə edən marşrut dok stansiyaları, USB adapterləri və konteyner körpüləri gəlib-getdikdən sonra ortaya çıxır. Onu bir dəfə silmək son deyil: NetworkManager bağlantı profilləri, netplan faylları və Windows davamlı marşrutları növbəti qoşulma və ya yüklənmədə onu yenidən quraşdırır, buna görə hər hansı dəyişiklik etməzdən əvvəl ona sahib olan faylı və ya profili tapın.

Sonra IPv6-nı ayrıca yoxlayın. ip -6 route və Get-NetRoute -AddressFamily IPv6 ayrı vəziyyət, ayrı defaultlar və ayrı müştəri davranışı saxlayır. Yalnız IPv4 auditı səssizcə doğma IPv6 yoluna üstünlük verən ikili stek hostu haqqında heç nə demir və tək bu, müştərini split-tunel görünüşünə sala bilər.

Tətbiqin öz axını ilə təsdiqləyin

Tətbiqin həqiqətən istifadə etdiyi təyinatı qeyd edin, sonra sistemdən həmin tətbiqin bağladığı mənbə ünvanından gedəcəyi yolu soruşun. ip route get 10.20.5.9 from 192.168.1.40 Linux-da buna cavab verir; Find-NetRoute -RemoteIPAddress 10.20.5.9 üstəgəl lokal ünvan Windows-da bunu edir. Nəticəni profilin iddia etdiyi ilə müqayisə edin. Brauzerin ictimai IP səhifəsi bir protokolda bir təyinatı yoxlayır və şikayətə səbəb olan özəl ünvan haqqında heç nə demir.

Fərqi izah edən ən dar obyekti düzəldin. İstisna təsdiqlənibsə, prefiksi yazın və ona toxunmayın; deyilsə, marşrutu silin və ya default metriyini aşağı salmaq əvəzinə tuneldən keçən açıq daha dar marşrut əlavə edin. Metriyi aşağı salmaq daha uzun prefiksi üstələyə bilməz və iki /1 marşrutu internet yoluna sahibkən defaultu redaktə etmək də heç nəyi dəyişmir.

Sonra tuneli yenidən qoşun və eyni sorğunu təkrarlayın. Müştərilər hər qoşulmada marşrutları yenidən quraşdırır, buna görə yalnız növbəti handshake-ə qədər davam edən dəyişiklik sınaqdan keçirilməyib. Yol hələ də fərqlənirsə, qalan şübhəlilər siyasət qaydası, ikinci cədvəl və ya müştəri tərəfli filtrdir — default marşrut deyil.

• Tətbiqin həqiqətən istifadə etdiyi təyinatı və mənbə ünvanını göstərin.
• Qalib marşrutu ip route get və ya Find-NetRoute ilə çap edin.
• İnternet yoluna /1 cütünün yoxsa siyasət cədvəlinin sahib olduğunu yoxlayın.
• Təyinata uyğun gələn /0-dan uzun hər prefiksi sadalayın.
• IPv6 yoxlamasını ayrıca təkrarlayın.
• Qalan marşrutu onu quraşdıran fayla, profilə və ya filtrə qədər izləyin.
• Düzəldildi deməzdən əvvəl yenidən qoşulun və sorğunu təkrar işə salın.

Əgər yeddisi də profillə uyğundursa, tunel konfiqurasiya edildiyi işi dəqiq görür və düzəliş metriyə deyil, profilə aiddir.