LAN serverində VPN klienti: cavablar niyə yanlış yolla çıxır

Simptomlar bir formanı izləyir: host işləyir, sonra klient kimi VPN-ə qoşulur və indi LAN klientləri ona çatır, cavabları isə yox olur. Hostda çəkilən tutma cavabların LAN interfeysi yerinə tunel cihazından çıxdığını göstərir. Tuneldə heç nə sınmayıb və düzəliş marşrutdur, yenidən qoşulma deyil. Aşağıdakı dörd yoxlamanı sıra ilə aparın və ilk uğursuz olanında dayanın.

Cavab yeni paketdir, əks gediş deyil

Cavabın sorğunun getdiyi yolla geri qayıtdığı fikrindən imtina etmək faydalıdır. Marşrutlaşdırma hər paket və hər istiqamət üzrə göndərən hostda qərar verilir. Tunelin içindən 10.64.0.23 ünvanından gələn sorğu heç bir geri yol yaratmır; host cavab verəndə həmin cavab yeni paket kimi cədvəllə tutuşdurulur və hansı marşrut qalib gəlirsə, ondan çıxır.

Buna görə LAN-a da xidmət edən maşında tam tunel klienti belə çaşdırıcı nasazlıq yaradır. Klient default marşrut, ya da bəzi klientlərin üstün tutduğu iki yarım-default marşrut quraşdırır və LAN klientinə cavab artıq tunelə uyğun gəlir. O, provayderə gedir, provayderin onu yönləndirməyə heç bir səbəbi yoxdur, LAN klienti isə host işlədiyi və yerli cavab verdiyi halda timeout görür. Tutma bunu aşkar edir, marşrut cədvəli isə izah edir.

Qalanını oxuyarkən iki alt şəbəkəni yadda saxlayın. Biri uzaq klientlərin gəldiyi VPN ünvan hovuzudur, bu nümunədə 10.64.0.0/24. Digəri işləməyə davam etməli olan LAN-dır, 172.16.24.0/24, marşrutlaşdırıcısı 172.16.24.1 ünvanındadır. Problem odur ki, aralarındakı trafik default marşrutla qərar verilir.

Bunu tutma və axtarışla sübut edin

Heç nəyi dəyişməzdən əvvəl cavabın hansı cihazdan istifadə edəcəyini təsdiqləyin. Axtarış tutmadan sürətlidir və paket qurularkən nüvənin verəcəyi cavabın eynisini verir.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Cavabı iki hissədə oxuyun. Əgər dev tun0 göstərirsə, host cavabı inkapsulyasiya edib provayderə verəcək və LAN klienti onu heç vaxt görməyəcək. Əgər dev eth0 göstərir, amma klient yenə timeout alırsa, marşrut artıq düzdür və paket daha sonra atılır, bu isə başqa problem və başqa düzəlişdir.

Eyni addımdakı tutma ping-in həll edə bilmədiyi şübhəni aradan qaldırır. LAN klientinə çatan əks-səda cavabı hansısa yolun işlədiyini sübut edir, onu hansı interfeysin daşıdığını yox, ona görə tutmanı hostun özündə aparın və kadrların haradan çıxdığına baxın. Eyni alt şəbəkədəki printer cavab verməyə davam edir, çünki onun birbaşa marşrutu tunelin default marşrutundan daha dəqiqdir. Yönləndirilmiş port hər hansı digər axın kimi uğursuz olur, çünki interfeysi cədvəl seçir, bağlantı yox.

Tuneli üstələyən ən dar marşrutu quraşdırın

Metrik yox, prefiks uzunluğu qərar verir, ona görə klient hovuzu üçün LAN marşrutlaşdırıcısından keçən marşrut VPN klientinin quraşdırdığı hər hansı defaultdan üstün gəlir. Metrik cərrahiyyəsinə ehtiyac yoxdur və default klientin qoyduğu yerdə qala bilər.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

add yerinə replace istifadə edin, çünki yenidən qoşulan klient öz qeydini quraşdırmış olacaq və ikinci add icazə problemi kimi oxunan mövcud-marşrut xətası verir. Windows hostda ekvivalent route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p əmridir, burada -p qeydi yenidən başlatmalar arasında saxlayır, çünki tunel yenidən qalxanda klient cədvəli yenidən qura bilər. Müasir Windows hostda dəstəklənən ekvivalent New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore əmridir və köhnə route əmri köhnə forma kimi saxlanılır.

Bir detal bunun düzgün, yoxsa sadəcə inandırıcı olduğunu həll edir: növbəti hop klientlərə geri yolu həqiqətən sahiblənən marşrutlaşdırıcı olmalıdır. Marşrutu özü tuneldən keçən ünvana yönəltmək, təmiz nasazlıq yerinə fasiləli itki kimi görünən dövrə yaradır. Sətri qeyd etməzdən əvvəl növbəti hopun LAN alt şəbəkəsində olduğunu təsdiqləyin.

Yenidən qoşulmadan sonra cavabı saxlayın

Əl ilə əlavə edilən marşrut ən yaxşı halda növbəti yenidən qoşulmaya qədər yaşayır. Klient hovuzu dinamikdirsə, onu server konfiqurasiyasında bərkidin ki, marşrutlaşdırdığınız prefiks klientlərin aldığı prefiks qalsın; əks halda qeyd boş diapazona işarə edir və simptom həftələr sonra aşkar səbəb olmadan qayıdır. Marşrutu klientin öz up-skriptinə yazmaq digər etibarlı seçimdir, çünki klient cədvəli yenidən yazdıqdan sonra işləyir.

Vəziyyət saxlayan firewall düzgün marşrutu yenə də poza bilər. İndi tutma cavabın eth0-dan çıxdığını göstərirsə və klient hələ də timeout alırsa, hostun paketi göndərilməzdən əvvəl atıb-atmadığını yoxlayın. ciddi əks yol filtri və net.ipv4.conf.all.rp_filter-in 1-ə qoyulması, mənbəyi gəldiyi interfeysdən geri marşrutlaşdırılmayan paketləri atır, bu da indicə yaratdığınız və sonra düzəltdiyiniz asimmetrik haldır, konntrak vəziyyəti yönləndirilmiş portlar üçün eyni hekayəni danışır.

Son yoxlama insanların atladığı yoxlamadır: tunel enib yenidən qalxdıqdan sonra axtarışı təkrarlayın. Dörd dəyər yazdığınızla uyğun gəlməlidir, təyinat, növbəti hop, cihaz və seçilmiş mənbə. Əgər onlardan hər hansı dəyişibsə, klient cədvəli yenidən yazıb və düzəliş shell tarixçəsində deyil, onun hook-larındadır.