OpenVPN iroute və kernel marşrutu: hansı çatışmır?
Serverdə marşrut var, trafik isə yenə dayanır. Yol qərarının biri kernelə, digəri peerə aiddir; hansının çatışmadığını və nəyi yoxlamaq lazım olduğunu öyrənin.
10.77.20.0/24 ünvanı üçün paket OpenVPN serverində iki ayrı qərar verir: əməliyyat sistemi onu VPN interfeysinə ötürməlidir və OpenVPN hansı qoşulmuş klientin həmin prefiksə sahib olduğunu bilməlidir. Çatışmayan kernel marşrutu paketi tuneldən əvvəl atır, çatışmayan peer marşrutu isə ondan sonra atır. Hər iki nasazlıq uzaq LAN-dan eyni görünür və hansının sizdə olduğunu diaqnostika etmək hər tərəfdə bir əmr tələb edir.
Klassik istifadəçi sahəsi məlumat yolunda kernel marşrutu paketi tunel prosesinə çatdırır və iroute həmin prosesə paketi hansı peerin alacağını deyir. Heç biri digərini əvəz etmir və yalnız birini daşıyan konfiqurasiya ilk pingə qədər məqul görünəcək.
İki qərar, bir marşrut deyil
Təsəvvür edin ki, saytlararası bağlantıda 10.77.20.0/24 tək bir klientin arxasındadır. Serverin kernel marşrutu, məsələn ip route add 10.77.20.0/24 dev tun0, uyğun paketləri tunel cihazına göndərir. Sonra OpenVPN klient konfiqurasiya qovluğundakı iroute qeydlərindən qurulmuş öz daxili cədvəlinə baxaraq hansı peer bağlantısının onları alacağını qərarlaşdırır. Kernel marşrutu olmadan paket prosesə heç vaxt çatmır, peer marşrutu olmadan isə prosesə çatır və heç yerə getmir.
Bu bölgü asanlıqla unudulur, çünki klient profilindəki bir marşrut sətri hər iki işi görürmüş kimi görünə bilər. Amma görmür: marşrutun itələnməsi klientlərə tuneldən nəyi göndərəcəyini deyir, iroute isə serverə klientin arxasındakı ünvan diapazonunun kimə aid olduğunu deyir. Onlar fərqli fayllarda yaşayır, fərqli tərəflər tərəfindən oxunur və əks istiqamətlərdə uğursuz olur.
iroute harada yerləşir və nə deyir
Qeyd klientin common_name adı ilə adlandırılmış fərdi faylda, client-config-dir altında, iroute 10.77.20.0/24 kimi yazılır. Fayl adının uyğunluğu kosmetik deyil: OpenVPN autentifikasiya olunmuş kimliyi tapır və faylı məhz həmin adla oxuyur, buna görə site-a adlı fayl yalnız ümumi adı site-a olan klient üçün qüvvəyə minir. Əgər belə faylı olmayan klientlərin tamamilə rədd edilməsini istəyirsinizsə, ccd-exclusive əlavə edin; hər klient sayt şlüzudursa, doğru parametr budur. Hər şlüz üçün bir fayl saxlayın və onu həqiqətən verdiyiniz sertifikat subyektinin adı ilə adlandırın.
Uzaq LAN-ı günahlandırmadan əvvəl qeydi serverdən yoxlayın. Status faylı qoşulmuş klientləri ümumi adları ilə sadalayır və --verb 4 ilə işləyən server peer qoşularkən iroute-un quraşdırıldığını jurnala yazır. Qoşulma anında heç nə görünmürsə, fayl səhv qovluqdadır və ya səhv kimliyi göstərir.
Tələ: fayl var, kimlik səhvdir
Səhv peerə bağlanmış düzgün görünən iroute çatışmayan fayldan daha çox vaxt itirir, çünki diskdə hər şey düzgün görünür. Sertifikatların adının dəyişdirilməsi, təkrar ümumi adlar və effektiv kimliyi dəyişən username-as-common-name bunların hamısı bu nəticəni verir. Gözlədiyiniz kimliyi deyil, serverin hansı kimliyi autentifikasiya etdiyini yoxlayın: status çıxışı səlahiyyətlidir, fayl adı isə yalnız axtarış açarıdır.
Marşrut öz sahibindən də uzun yaşaya bilər. Statik marşrutlar və iroute qeydləri mövcudluq zəmanəti deyil, prefiks təsvir edir, buna görə trafik hazırda qoşulmamış peerə doğru yönəlməyə davam edə bilər.
Yolu peerin arxasına qədər tamamlayın
Peer sahibliyi yolun sonu deyil, ortasıdır. Klient paketləri tuneldən öz LAN-ına ötürməlidir, yəni həmin hostda IP ötürmə aktiv olmalı və keçidə icazə verən firewall qaydası olmalıdır. Uzaq LAN-dakı hostlar tunel ünvanı üçün geri yol tələb edir: ya şlüza geri baxan marşrut, ya da klient tərəfində qəsdən hazırlanmış NAT dizaynı. Klientdə ötürmə parametrini distributiv defoltunu fərz etməklə deyil, sysctl net.ipv4.ip_forward ilə təsdiqləyin.
Digər VPN klientləri həmin alt şəbəkəyə çıxmalıdırsa, quruluş yenidən böyüyür: serverə client-to-client lazımdır və həmin klientlər prefiksi tuneldən keçirməlidir. Bunların heç biri serverin öz marşrut cədvəlindən irəli gəlmir.
Bir təyinatı serverin özündən deyil, real mənbədən yoxlayın. Əlaqəsiz LAN hostundan klientin arxasındakı hosta ping geri yolu, ötürmə qaydasını və peer sahibliyini bir hərəkətdə sınaqdan keçirir, uğurlu handshake isə yalnız kimliyi sübut edir. Sonra sahib peeri ayırın və marşrutun nə etdiyini qeyd edin, çünki həmin cavab sizin nasazlıq modelinizdir.