Bir LAN alt şəbəkəsini OpenVPN-dən keçir və standart marşrutu saxla

LAN üçün marşrutlaşdırma edən və eyni zamanda VPN-ə qoşulan qurğular özləri ilə eyni mübahisəyə düşür: tunel standart marşruta sahib olmaq istəyir, LAN isə onu geri istəyir. OpenVPN qoşulduqda tuneldən keçən standart marşrut və ya bir cüt yarım-standart quraşdıra bilər; bu noutbuk üçün düzgün, qonşuları onun LAN ünvanından cavab gözləyən şlüz üçün isə yanlışdır. Cavab VPN-i atlamaq deyil. Cavab iki qərara fərqli cədvəllər verməkdir.

Bir standart marşrut, iki sahib

Yönləndirilən trafik və yerli yaranan trafik eyni yolu getmək məcburiyyətində deyil. LAN müştəriləri tunelə yalnız sizin seçdiyiniz təyinatlar üçün ehtiyac duyur, hostun öz idarəetmə sessiyaları və həmin müştərilərə cavabları isə LAN standart marşrutuna ehtiyac duyur. İkisini əsas cədvəldə qarışdırmaq iki fərqli suala tək cavab verməyə məcbur edir.

OpenVPN-də məhz bunun üçün bir açar var. route-noexec müştərini əsas cədvələ ümumiyyətlə toxunmaqdan saxlayır, istifadə edəcəyi dəyərlər isə route-up skriptinə route_vpn_gateway, dev və interfeys ünvanları kimi ötürülür. Sonra hansı cədvəlin hansı marşrutu alacağına siz qərar verirsiniz, sonradan oxuya biləcəyiniz kodda.

Siyasət cədvəli əsas cədvəlin yenidən yazılmasına qarşı

Ayrı cədvəl bir alt şəbəkədən kənara miqyaslanan yeganə variantdır. Ona bir dəfə ad verin, sonra adı ilə istinad edin ki, heç kim rəqəm yadda saxlamaq məcburiyyətində qalmasın:

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

Buradakı ünvanlar nümunədir. Heç nə işə salmazdan əvvəl LAN prefiksini, tunel şlüzünü və cihaz adını öz yerləşdirmənizdən götürüb dəyişdirin.

Qayda hostla da uyğunlaşmalıdır

Yalnız LAN prefiksinə uyğun gələn qayda yönləndirilmiş paketləri əhatə edir. O, şlüzün özünün yaratdığı trafiki əhatə etmir və LAN müştərilərinə qaytardığı, mənbə kimi şlüzün LAN ünvanını daşıyan cavabları da əhatə etmir. Həmin axtarışlar main cədvəlinə düşür və hələ də tuneldən çıxa bilər.

Şlüzün öz LAN ünvanı üçün ikinci qayda əlavə edin və ya birinci qaydanı hər ikisini əhatə edən çoxluğa genişləndirin. Sıra vacibdir: daha dəqiq qaydayı birinci qoyun və nəticəni mənbəni açıq şəkildə göstərən axtarışla yoxlayın.

ip route get 203.0.113.9 from 192.168.50.1

Əgər bu, yerli qalmalı olan təyinat üçün tunel cihazını göstərirsə, cədvəlin nə saxladığından asılı olmayaraq qayda dəsti yanlışdır.

NAT yoxsa uzaq tərəfdə marşrut

VPN serveri tunel alt şəbəkəsini bilir və başqa heç nə bilmir. LAN mənbə ünvanı ilə gələn paketlərin qayıdış yolu yoxdur, məgər kimsə onu təmin etsə, və bunu təmin etməyin dəqiq iki yolu var. Serverdə LAN prefiksi üçün marşrut əlavə etmək orijinal mənbəyi başdan-başa görünən saxlayır, auditdən keçən dizaynın adətən istədiyi də budur. Şlüzdə maskalama mənbəni tunel ünvanına yenidən yazır və serverdən heç bir əməkdaşlıq tələb etmir.

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Serveri idarə etmirsinizsə və ora marşrut əlavə edə bilmirsinizsə, NAT seçin. Jurnallar, giriş nəzarəti və ya qayıdış yolu simmetriyası vacibdirsə, server tərəfində marşrutu seçin, çünki maskalama orijinal ünvanı uzaq tərəfin qeyd etdiyi hər şeydən silir.

Hər iki halda yönləndirmə aktiv olmalıdır və sərt tərs yol filtrləməsi, main həmin mənbə üçün tuneli seçmədiyi halda cavabı ata bilər. Tuneli günahlandırmazdan əvvəl effektiv dəyəri yoxlayın.

Bölünməni yenidən qoşulmadan sonra da yaşatmaq

Əl ilə əlavə edilmiş qaydalar və marşrutlar interfeys yenidən yaradılanda yox olur, köhnə cədvəl qeydi isə onu əsaslandıran sessiyadan uzun yaşaya bilər. Cədvəl qaydasını, tunel marşrutunu və maskalama qeydini müştərinin route-up skriptinin içinə qoyun və skriptin başında cədvəli təmizləyin ki, köhnə şlüz yeni sessiyada yaşaya bilməsin.

Hər iki tərəfdən yoxlayın: şlüzdə LAN mənbəyi ilə axtarış, və LAN müştərisindən tuneldən keçməli olan təyinat ünvanına real sorğu. Mövcud olub heç vaxt seçilməyən marşrut, sayğacları oxuyana qədər tam olaraq marşrutsuz kimi davranır.