VPN marşrutunda növbəti atlama: şlüz niyə lokal şəbəkədə əlçatan olmalıdır

VPN şəbəkəsinə gedən marşrut asanlıqla qarışdırılan iki ünvan daşıyır: paketin çatmaq istədiyi təyinat prefiksi və onu bir addım yaxınlaşdıracaq növbəti atlama. LAN hostunda bu növbəti atlama həqiqətən eyni keçiddə çata bildiyiniz marşrutlaşdırıcı olmalıdır. Uzaq VPN ünvanı növbəti atlama deyil, nə qədər səliqəli şəkildə nəzərdə tutduğunuz təyinatla üst-üstə düşsə də.

Bu təlimat adi halı əhatə edir: 192.168.20.0/24 üzərində noutbuk, LAN ünvanı 192.168.20.5 olan VPN şlüzü və həmin şlüzün arxasında 10.70.0.0/24 uzaq şəbəkəsi. Aşağıdakı bütün əmrlər başqa cür göstərilmədikcə noutbukda olduğunuzu fərz edir.

İki ünvan, bir marşrut

Nəzərdə tutulan giriş 10.70.0.0/24 via 192.168.20.5-dir. Prefiks paketin hara getdiyini, via ünvanı isə onu ora kimin apardığını bildirir. Nüvə şlüzünə adlandırdığınız interfeys vasitəsilə çata bilmədiyi marşrutu quraşdırmaqdan imtina edir və bu imtina bütün məsələnin özüdür: tunelin əlçatan olmasına ehtiyac duyan növbəti atlama tuneli quran növbəti atlama ola bilməz.

Deməli ilk yoxlama «şlüz işləyir» deyil, «şlüz bu keçiddədir» olmalıdır. Noutbukun öz alt şəbəkəsi, onun ARP və ya qonşu qeydi və marşrutdakı interfeys hamısı uyğun olmalıdır. Yalnız 10.70.0.0/24 daxilində mövcud olan ünvan ikinci marşrutun təyinatı ola bilər, birincinin via heç vaxt ola bilməz.

Növbəti atlamanın şlüzü öhdəsinə götürdüyü iş

Marşrutun noutbukda quraşdırılması yalnız ilk ötürməni həll edir. Sonra şlüzün öz yoluna ehtiyacı var: yönləndirmə aktiv, 10.70.0.0/24 üçün tunel marşrutu və ondan kimin istifadə edə biləcəyini tənzimləyən istənilən giriş siyasəti. Linux-da bu net.ipv4.ip_forward=1 və tunel marşrutudur; qarşısındakı firewall isə yönləndirilən axına icazə verən qayda tələb edir.

Geri istiqamət insanların unutduğu hissədir. Uzaq tərəfin 192.168.20.0/24 üçün geri marşrutu olmalıdır, ya da dizayn noutbukun mənbəyini uzaq tərəfin tanıdığı bir şeyə çevirməlidir. Şlüzdən işləyən ping şlüzün uzaq şəbəkəyə çata bildiyini sübut edir; noutbukun paketlərinin geri yolculuğu keçib-keçmədiyi barədə heç nə demir.

Axtarışı göndərən hostdan yoxlayın

Nüvədən hansı növbəti atlamanı seçəcəyini soruşun və cavabdakı interfeysi oxuyun:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Axtarış şlüzü və LAN interfeysini göstərirsə, birinci ayaq nəzərdə tutulduğu kimi qurulub. Tunel cihazını göstərirsə, cədvəldə daha əvvəlki bir şey daha dəqiqdir və qalib gəlir. Marşrut heç quraşdırılmırsa, nüvə sizə şlüzün əlçatmaz olduğunu deyir və bu mesaj istənilən paket tutmasından daha faydalıdır.

Sonra sınağı düzgün yerdən təkrarlayın. Şlüz üzərində yaradılan sorğu şlüzün öz mənbə ünvanını istifadə edir, bu da itkin geri marşrutu və ya yalnız müəyyən mənbələrə icazə verən siyasəti gizlədə bilər. ip-route təlimatı təyinatı, şlüzü və onlink ləğvetməsini ayırır və bu ləğvetmə istifadə etməzdən əvvəl anlaşılmağa dəyər.

Əlçatanlığı saxtalaşdırmaq üçün onlink istifadə etməyin

onlink nüvəyə şlüz üçün əlçatanlıq yoxlamasını atlayıb yenə də ona göndərməyi deyir. O, yol yaratmır, mövcud olmayan ünvan üçün ARP həll etmir və uzaq marşrutlaşdırıcının Ethernet seqmentinizdə cavab verməsinə səbəb olmur. Cavab verən, lakin qoşulmuş alt şəbəkədə olmayan şlüzlər üçün qanunidir və izah etmədiyiniz xətanı susdurmaq üçün istifadə edildikdə tələdir.

Marşrut yalnız onlink ilə quraşdırılırsa, növbəti sual şlüzün niyə düşündüyünüz yerdə olmadığıdır. Səhv VLAN, səhv interfeysdə ikinci ünvan və ya son oktetdə yazı səhvi bunların hamısını yaradır və hər biri trafik axmağa başlayanda geri yolu da pozur.

Nöqtədən-nöqtəyə tunellər Ethernet deyil

Tunel cihazı ARP etmir və çox vaxt qonşuların mənalı alt şəbəkəsi olmur. Onun marşrutları tez-tez 10.70.0.0/24 dev tun0 kimi görünür, heç bir via olmadan, çünki peer yeganə digər son nöqtədir. LAN üslublu via-i həmin cədvələ köçürmək nüvənin rədd edə biləcəyi və ya daha pisi, peerin heç vaxt cavab vermədiyi ünvana işarə edən marşrut yaradır.

Təlimatlarda iki modeli ayrı saxlayın: LAN marşrutunun əlçatan şlüzü var, tunel marşrutunun interfeysi və peeri var. WireGuard, OpenVPN və IPsec hamısı bir qədər fərqli formalar təqdim edir, ona görə bir hostdan ümumiləşdirmək əvəzinə həqiqətən istifadə etdiyiniz formanı qeyd edin.

Əlavə et, təsdiqlə, geri qaytar

Bütün dəyişiklik üç əmr və bir yoxlamadır və bu sıra ilə yazılmalıdır:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Yolu təsdiqləyin, bir təyinatı təsdiqləyin, sonra dəyişikliyin hostu gözləmədiyiniz şəkildə əlçatmaz etməsi halında silmə sətrini hazır saxlayın. Marşrut yenidən başlatmadan sonra qalmalıdırsa, onu shell profilində deyil, hostun şəbəkə konfiqurasiyasında yerləşdirin və ona güvənməzdən əvvəl yenidən başlatmanı sınayın. Yalnız onu əlavə edən shell-də mövcud olan marşrut iki dəfə sazlayacağınız marşrutdur.