LAN marşrutlaşdırıcısı və VPN müştərisi: iki cihaz, iki marşrut cədvəli

İki cihaz paketi yönləndirir və hər biri öz cədvəlini saxlayır. LAN marşrutlaşdırıcısı uzaq prefiksin VPN müştərisinə aid olduğunu bilir, VPN müştərisi isə həmin prefiksə öz tuneli vasitəsilə necə çatacağını bilir. Yalnız birinci cədvəli konfiqurasiya etsəniz, paket uyğun marşrutu olmayan maşına çatır və yenidən defolt marşrutla çıxır. Bütün nasazlıq budur və LAN tərəfindən bu, marşrut dövrəsi kimi görünür, çünki demək olar ki, elə dədir.

Marşruta toxunmazdan əvvəl iki atlamanı çəkin

Nümunəvi bir sxem götürün: LAN hostları 192.168.50.0/24, adi marşrutlaşdırıcı 192.168.50.1, ayrılmış müştəri 192.168.50.15 və yalnız həmin müştərinin saxladığı tunel vasitəsilə əlçatan uzaq LAN 10.60.0.0/24. Heç bir özəl diapazon digəri ilə üst-üstə düşmür, və tunelin öz ünvan planı var.

Hər iki özəl diapazon vacibdir, çünki hansı cihazın cavab verə biləcəyini onlar müəyyən edir. Uzaq tərəf paketin müştərinin tunel ünvanından gəldiyini görəcək və onun cavabı 192.168.50.0/24 ünvanına geri yol tapmalıdır. Yalnız çıxış istiqaməti konfiqurasiya olunubsa, sorğu işləyə bilər, cavab isə yox olar.

Addım 1: marşrutlaşdırıcını tunelə deyil, müştəriyə yönəldin

LAN marşrutlaşdırıcısında növbəti atlaması müştərinin LAN ünvanı olan təyinat marşrutu əlavə edin:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Bu qeyd “paketi tunel qura bilən maşına çatdır” deyir. Tunelin necə qurulduğu barədə heç nə demir və müştərinin öz marşrutunu əvəz etmir. İdarə olunan marşrutlaşdırıcıda ekvivalent cihazın statik marşrut səhifəsində yaşayır; Linux marşrutlaşdırıcısında isə LAN-a sahib interfeys konfiqurasiyasına aiddir, bağlayacağınız shell-ə deyil.

İkinci əmrin cavabına baxın. Əgər o, müştərini gateway, LAN interfeysini isə device kimi göstərirsə, birinci atlama düzdür və qalan iş digər maşındadır.

Addım 2: müştəriyə tunel tərəfində öz marşrutunu verin

Müştəri indi 10.60.0.0/24 üçün paket alır və öz cədvəlinə baxır. Əgər tunel konfiqurasiyası həmin prefiks üçün marşrut quraşdırıbsa, paket şifrələnmiş şəkildə davam edir. Əgər quraşdırmayıbsa, paket adi defolta uyğun gəlir və 192.168.50.1 ünvanına qayıdır, o da onu yenidən müştəriyə göndərir.

Nə isə əlavə etməzdən əvvəl baxın:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Bütün cədvəllərdə prefiks marşrutunun olmaması axtardığınız tapıntıdır. Onu tunelin öz konfiqurasiyası vasitəsilə əlavə edin ki, növbəti yenidən qoşulma onu yenidən quraşdırsın; əl ilə verilən ip route add sessiya ilə birlikdə yox olur və nasazlığı ən əlverişsiz vaxtda qaytarır. Növbəti atlama tunel interfeysi və ya VPN-in həmkar kimi təyin etdiyi ünvandır, müştəridən asılı olaraq, və həmkar ünvanı köhnə qeyddən deyil, cari profildən gəlməlidir.

Dövrə, baş verdikdə, praktikada sonsuz deyil: hər keçiddə TTL azalır və paket vaxt aşımı mesajı ilə ölür. Buna görə təkrarlanan traceroute dövrə işarəsi verə bilər, halbuki sadəcə yönləndirməyən müştəri eyni paketi səssizcə atır.

Addım 3: yönləndirməyə icazə verin və geri dönüş yolunu seçin

Qəbul etmək və yönləndirmək fərqli icazələrdir. Müştəridə net.ipv4.ip_forward=1 kernel səviyyəsində tranzitə icazə verir, lakin firewall qaydası hələ də onu LAN interfeysi ilə tunel arasında icazəli etməlidir. Müştərinin öz idarəetmə səhifəsinə girişə icazə verən qayda uzaq LAN-a tranzitə icazə verməyəcək və eyni host yerli olaraq ping-lərə cavab verəndə bu fərqi qaçırmaq asandır.

Uzaq tərəfin güzgü problemi var. O, 192.168.50.0/24 ünvanının bu autentifikasiya olunmuş müştəri vasitəsilə əlçatan olduğunu bilməlidir. OpenVPN ilə bu, adətən, server konfiqurasiyasının itələdiyi hər müştəri üçün marşrut, ya da serverdə müştərinin arxasındakı LAN-ı elan edən müştəriyə xas fayl deməkdir. Bu olmadan uzaq LAN ya cavabı atır, ya da öz defolt şlüzünə, yəni internetə göndərir.

LAN prefiksi elan edilə bilməyəndə mənbə tərcüməsi alternativdir. Müştəridə məhdud əhatəli masquerade qaydası mənbəni tunel ünvanına yenidən yazır və cavablar təbii şəkildə qayıdır. Bu həm də hansı LAN hostunun sorğu göndərdiyini gizlədir və özlüyündə uzaq tərəfə içəriyə doğru bağlantı başlatmağa imkan vermir. Bu güzəşti qəsdən seçin, hər şeyi əhatə edən masquerade əlavə edib yan təsiri sonra kəşf etməkdənsə.

Addım 4: hər iki qərarı qalıcı edin, sonra real yolu sınaqdan keçirin

Hər marşrutun bir sahibi var və sahib yüklənmə zamanı və ya yenidən qoşulma zamanı bərpa olunan konfiqurasiyadır. Marşrutlaşdırıcıda bu, statik marşrut qeydi ola bilər; müştəridə bu, VPN profili, NetworkManager və ya systemd-networkd ola bilər. Tuneli yenidən qoşub müştərini yenidən başladaraq yoxlayın, sonra redaktəyə güvənməkdənsə cədvəli yenidən oxuyun.

Tunelin xarici bağlantısını daşıyan defolt marşrutu toxunulmaz saxlayın. Qurğunu “sadələşdirmək” üçün onu əvəz etmək şifrələnmiş yolu hər hansı daxili trafik ondan istifadə etməzdən əvvəl pozur və simptom dəyişiklikdən sonra heç vaxt bərpa olunmayan tuneldir.

Adi LAN hostundan sınayın, müştəridən yox, çünki müştəridə yaranan sorğu heç vaxt marşrutlaşdırıcının birinci atlamasını işə salmır. Yalnız uzaq LAN-da mövcud olan bir xidməti gətirin və cavab gövdəsini təsdiqləyin, sonra tranzitin baş verdiyini görmək üçün müştərinin sayğaclarına və ya qeydlərinə baxın. Özəl atlamalar göstərən daxili traceroute yönləndirməni sübut edir, şifrələməni yox: xarici yol ayrı bir müşahidədir və yalnız tunelin öz interfeys sayğacları ondan nəyin çıxdığını göstərir.