OpenVPN klienti serverə çatır, lakin LAN hostlarına çatmır: yoxlama siyahısı

Klient bağlandığını bildirir, tunel ünvanı ping sorğusuna cavab verir və ofis LAN-ında heç nə cavab vermir. Mən bunu demək olar ki, hər klient yeniləməsindən sonra görürəm və ilk instinkt firewall-u açmaqdır, bu isə adətən yanlış addımdır: tunel sağlamdır və qırılma paketin keçməli olduğu üç atlamadan biridir. Yolu paketin getdiyi sıra ilə gəzin, əvvəlcə klient marşrutu, sonra serverin yönləndirməsi, sonra qayıdış səfəri və bir neçə dəqiqə ərzində nasazlığın sahibini tapacaqsınız.

Birinci addım: klientin marşrut qərarını izləyin

Serverə toxunmadan əvvəl klientin paketi tunelə göndərdiyini sübut edin. Bütün cədvəli oxumaq əvəzinə nüvədən konkret bir LAN hostu üçün hansı interfeysdən istifadə edəcəyini soruşun:

ip route get 192.168.50.10

Əgər cavab fiziki adapterinizi və ofis şlüzünü göstərirsə, server tərəfində heç bir dəyişiklik kömək edə bilməz. OpenVPN marşrutları yalnız server onları itələdikdə paylayır, ona görə server konfiqurasiyasında push "route 192.168.50.0 255.255.255.0" axtarın və sonra klienti yenidən qoşun. Əksər klientlər itələnmiş marşrutları qoşulma zamanı tətbiq edir, profili yenidən yüklədikdə deyil.

Windows-da eyni sualın fərqli əmri var. Find-NetRoute -RemoteIPAddress 192.168.50.10 yığının seçəcəyi interfeysi və növbəti atlamanı çap edir, route print -4 isə itələnmiş prefiksin ümumiyyətlə mövcud olub-olmadığını göstərir.

İkinci addım: serverin paketi yönləndirəcəyini təsdiqləyin

Klient marşrutu düzdürsə, paket serverə çatır və server onu yönləndirməyə razı olmalıdır. Nüvə açarı birinci qapıdır və sysctl net.ipv4.ip_forward 1 qaytarmalıdır. Onu echo 1 > /proc/sys/net/ipv4/ip_forward ilə qurmaq növbəti yenidən başlatmaya qədər işləyir və eyni şikayətin həftələr sonra qayıtmasının səbəbi məhz budur.

Onu yenidən başlatmadan sonra da qalan bir yerə yazın:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

İkinci qapı filtr cədvəlidir. Docker quraşdırılmış host tez-tez FORWARD siyasəti kimi DROP daşıyır və tunel bu qərarı miras alır. iptables -L FORWARD -v -n həm siyasəti, həm də paket sayğaclarını göstərir; siyasət DROP-dursa, yönləndirmə tuneldən LAN-a istiqaməti üçün bir, cavab üçün də bir açıq icazə tələb edir.

Üçüncü addım: paketi LAN-a qədər izləyin və cavabı axtarın

Serverin hər iki tərəfini eyni vaxtda izləyin. Tuneldə və LAN interfeysində, bir klient və bir host üzrə filtrləyərək tutun ki, çıxış oxunaqlı qalsın:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Mənbəyi 10.8.0.x olan və tun0 üzərində, sonra yenidən eth0 üzərində görünən, ardınca sükut gələn sorğular paketin gəldiyini və cavabın başqa yerə getdiyini bildirir. LAN hostu öz defolt şlüzünə cavab verir, o şlüzün VPN hovuzu üçün marşrutu yoxdur və cavab LAN marşrutlaşdırıcısında ölür. LAN hostunu serverdən ping etmək bu yol haqqında heç nə sübut etmir, çünki o trafik heç vaxt tuneldən keçmir.

Dördüncü addım: tərcümə ilə qayıdış marşrutu arasında seçim edin

İki düzəliş dəliyi bağlayır və seçimin ping işləyib-işləməməsindən kənar nəticələri var. Mənbə tərcüməsi serveri zahiri göndərən edir:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Qaydanı hovuzla və LAN interfeysi ilə məhdudlaşdırın, sonra onu qalıcı edin, əks halda növbəti firewall yenidən yükləməsi düzəlişinizi səssizcə silir. Qiymət kimlikdir: hər klient LAN jurnallarında və giriş qaydalarında VPN serveri kimi görünür və per-client policy becomes guesswork.

LAN marşrutlaşdırıcısında VPN serverinə baxan 10.8.0.0/24 üçün statik marşrut klient ünvanlarını görünən saxlayır və o marşrutlaşdırıcı sizin olduqda daha yaxşı uzunmüddətli cavabdır. Bir çox sayt bir müddət hər ikisini işlədir, dərhal düzəliş üçün NAT və firewall siyasəti yazıldıqdan sonra marşrutu. Əgər server hovuz deyil, saytlararası həmdirsə, server tərəfi uzaq alt şəbəkə üçün də iroute tələb edir, əks halda həmkar marşrutu mövcuddur, lakin klient trafiki heç vaxt onunla əlaqələndirilmir.

Beşinci addım: klientdən yoxlayın və nəyin dəyişdiyini qeyd edin

Dövrəni serverdən deyil, klientdən bağlayın. LAN hostunda real xidmətə qoşulun, sonra iptables -t nat -L POSTROUTING -v -n ilə tərcümə sayğaclarının yerindən tərpəndiyini təsdiqləyin, çünki sıfır paketli qayda heç vaxt uyğun gəlməmiş qaydadır. Qayıdış istiqamətinin izləndiyinə dair sübut lazım olduqda conntrack -L -s 10.8.0.5 axını və onun vəziyyətini göstərir.

Server konfiqurasiyasında qeyd qoyun: hansı alt şəbəkə, hansı interfeys, hansı qayda və LAN marşrutlaşdırıcısının geri marşrutu olub-olmadığı. Növbəti dəfə klient yeniləməsi itələnmiş marşrutu sildikdə, bu qeyd yanğınsöndürmə sessiyasını bir sətirlik düzəlişə çevirir.