VPN müştərisinin arxasındakı server niyə tuneldən cavab verir
Cavablar gəliş yolunu deyil, VPN-in defolt marşrutunu izləyəndə gələn bağlantılar uğursuz olur. Siyasət əsaslı marşrutlaşdırma və ya mənbə NAT-ı dönüş yolunu bərpa edir.
VPN müştərisi də işlədən hosta gələn bağlantılar çox xüsusi bir şəkildə uğursuz olur: əl sıxışması gəlir, demon cavab verir, müştəri isə geri heç nə almır. Portu heç nə bloklamır. Cavab tuneldən çıxdı, çünki defolt marşrut tunelin əlindədir və nüvə cavabları sorğunun haradan gəldiyini yadda saxlamasına görə deyil, təyinatına görə marşrutlaşdırır. Demon qaydasındadır və port açıqdır.
Cavab yadda saxlanmır, marşrutlaşdırılır
Defolt marşrut quran VPN müştərisi LAN şlüzündən üstün olan bir giriş əlavə edir, ya metrikaya görə, ya da məkanı daha dəqiq iki yarıya bölməklə. Çıxan paketlər artıq tunel interfeysini seçir. Nüvə cavablandırılan paketin əvvəlcə haradan gəldiyini heç vaxt soruşmur. Bu tək buraxılış sonrakı bütün simptomları izah edir.
İrəli istiqamət təyinatına görə marşrutlaşdırılır, əks istiqamət də. Cavab açıq müştəriyə ünvanlanıb və tunel onu məmnuniyyətlə daşıyacaq. Uzaq tərəf mənbəyi özünə aid olmayan paket alır, onu atır, orijinal müştəri isə vaxt bitənə qədər gözləyir.
Ciddi tərs yol filtrləməsi gələn paketi demon onu oxumamışdan əvvəl atə bilər. Əvvəlcə həmin sayğacı yoxlayın, çünki filtr atması ilə marşrutlaşdırma səhvi kənardan eyni görünür.
ip route show default sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter nft list ruleset | grep -A3 'hook forward'
Birinci əmr hazırda hansı defoltun qalib gəldiyini göstərir. İkinci ciddi filtrin qlobal, yoxsa hər interfeys üzrə tətbiq olunduğunu bildirir, üçüncü isə aid ola biləcək hər hansı forward zənciri qaydasını göstərir.
Dönüş yolunu saxlamağın üç yolu
Xidmət təyinatını tuneldən kənarlaşdırmaq ən dar seçimdir. LAN şlüzünə tuşlanmış host marşrutu, üstəlik demonun hər ünvana deyil, fiziki ünvana bağlanması, o bir axını tuneldən kənarda saxlayır. Dəyişiklik yerlidir və geri qaytarmaq asandır.
Siyasət əsaslı marşrutlaşdırma ümumi cavabdır. Mənbə ünvanına və ya firewall işarəsinə bağlanan qayda, defoltu WAN şlüzünə baxan cədvəli seçir, hostun öz bağlantıları isə tuneldən istifadə etməyə davam edir. Prioriteti açıq saxlayın ki, qayda sonradan kölgədə qalmasın.
ip rule add from 203.0.113.25/32 table 100 priority 100 ip route add default via 192.0.2.1 dev eth0 table 100 ip route get 198.51.100.7 from 203.0.113.25
İlk iki əmr açıq ünvandan çıxan cavablar üçün alternativ yolu qurur. Üçüncü, həmin mənbə və təyinatın hansı yolu tutacağını nüvədən soruşur; qaydanın hər hansı təsiri olduğunu belə təsdiqləyirsiniz.
Mənbə tərcüməsi üçüncü seçimdir və xidmətin qarşısında artıq NAT edən marşrutlaşdırıcı qarşısında qalan yeganə seçimdir. Cavab həmin marşrutlaşdırıcıya qayıtmalıdır və WAN interfeysinə masquerading buna nail olur, eyni zamanda müştərini xidmət jurnallarından gizlədir. Qoşulduqdan sonra defolt marşrutu əl ilə dəyişmək diaqnostikadır, çünki müştəri növbəti yenidən qoşulmada cədvəli yenidən yazır.
Qutu həm də LAN üçün marşrutlaşdıranda
Eyni nasazlıq host arxasındakı cihazlar üçün marşrutlaşdıranda bir atlama sonra görünür. Gələn bağlantı yeganə dönüş yolu tunel olan daxili cihaza yönləndirilir və cavab xarici müştəriyə provayderin ünvanından çatır. Daxili cihaz bütün müddət düzgün işləyir.
Sonra bağlantı izləmə heç qeyd etmədiyi axın üçün cavab görür və onu atır. Təyinat tərcüməsi gələn bağlantını cihaza çatdırır, mənbə tərcüməsi isə cavabı sanki marşrutlaşdırıcının özündən çıxmış kimi göstərir.
Yönləndirilən portu WAN-da saxlayan, marşrutlaşdırıcının öz trafiki isə tuneldən istifadə edən siyasət marşrutu daha səliqəli ekvivalentdir. Mənbə tərcüməsi olmadan cavab xarici müştəriyə ünvanlanır və daxili cihazın o ünvana heç marşrutu olmur.
Səbəbləri ayıran üç yoxlama
Üç yoxlama aparın: internetdən qutuya bağlantı, ondan açıq hosta bağlantı və ad sorğusu. İlk ikisi ziddiyyət təşkil edəndə cavab yolu günahkardır. Adlar hər iki istiqamətdə uğursuz olarsa, həlledici sadəcə tuneli paylaşan başqa bir nasazlıqdır.
Əvvəlcə marşrutlaşdırma məsələsini düzəldin, sonra adlara baxın. İkisini qarışdırmaq işlək serverin pozulmuş həlledici üçün günahlandırılmasına səbəb olur.
İstisnanın hansı interfeysi adlandırdığını qeyd edin və konfiqurasiyanı versiya nəzarətində saxlayın. Yeniləmədən sonra adı dəyişən interfeysə qarşı yazılmış qayda bu gün keçir, növbəti yenidən başlatmadan sonra uğursuz olur.