VPN müştəriləri serverə çatır, LAN-a yox: hansı həll?

Müştəri OpenVPN serverinin tunel ünvanına ping edir və cavab alır, sonra serverin LAN-ındakı hostu yoxlayır və heç nə almır. Bu ayrım nasazlığı xeyli daraldır: tunel qalxıb, yönləndirmə yəqin işləyir, cavab isə geri qayıtmayan qapıdan çıxır. Üç həll var və düzgün olan nəyə nəzarət etdiyinizdən və nədən imtina etməyə hazır olduğunuzdan asılıdır. Aşağıdakı üç suala ardıcıl cavab verin və seçim daha zövq məsələsi olmayacaq.

Əvvəlcə hansı istiqamətin xarab olduğunu müəyyənləşdirin

Sorğu tunel interfeysinə VPN hovuzundan gələn mənbə ünvanı ilə gəlir. Server onu LAN hostuna yönləndirir və həmin host öz cədvəlinin göstərdiyi şlüzə cavab verir, adətən LAN marşrutlaşdırıcısına. Əgər marşrutlaşdırıcının hovuza marşrutu yoxdursa, cavab orada ölür və ya internetə doğru azır.

Hər ikisini dəyişməzdən əvvəl iki maşını da yoxlayın. Serverdən soruşun ki, onun cədvəli müştəriyə hansı yolla çatardı; LAN hostundan soruşun ki, o, eyni ünvana necə çatardı. Birinci axtarış adətən tuneli, ikincisi isə LAN marşrutlaşdırıcısını göstərir və bu fərq bir sətirdəki nasazlıqdır. İki axtarış firewall auditindən ucuzdur və problemin istiqamətini müəyyən edir.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Əgər LAN hostu artıq VPN serverini göstərirsə, probleminiz firewall qaydası və ya MTU həddidir, geri dönüş yolunun olmaması deyil. Filtri düzəltmək üçün marşrut əlavə etməyin.

Birinci sual: uzaq LAN-ın marşrutlaşdırıcısını redaktə edə bilirsinizmi?

LAN marşrutlaşdırıcısı sizindirsə, təmiz cavab VPN hovuzuna VPN serverinin LAN ünvanını növbəti atlama kimi göstərən statik marşrutdur. O, müştərilərin mənbə ünvanlarını toxunulmaz saxlayır, bu da LAN hostları ünvana görə jurnal yazanda, filtrləyəndə və ya sürəti məhdudlaşdıranda vacibdir. Serverdə tərcümə də tələb etmir, ona görə tunel təmiz marşrutlaşdırma yolu olaraq qalır. Yaradığı öhdəlik sənədləşdirmədir, çünki hovuz, marşrut və server konfiqurasiyası uyğun olmalıdır.

Kiminsə hovuzu dəyişdiyi gün səssizcə uğursuz olur. Dəyəri bir dəfə yazın və üç yerdən hər hansı birindəki dəyişikliyi üçünün də dəyişikliyi kimi qəbul edin.

Xidməti yerləşdirən NAS və ya Layer 3 kommutator eyni marşruta ehtiyac duyur, tək o hər şeyi bu marşruta sahib olan marşrutlaşdırıcıdan göndərmirsə. Alt şəbəkəni bitirən cihazı yoxlayın, təkcə internetə baxanı deyil. Kiçik şəbəkələrdə tez-tez marşrutlaşdırma barədə fikri olan üç cihaz olur.

İkinci sual: LAN müştəri ünvanlarını görməyi dayandıra bilərmi?

Marşrutlaşdırıcı başqasına aiddirsə, VPN serverində tərcümə əməkdaşlıq tələb etmir. LAN hostu serverin LAN ünvanını görür, ona cavab verir və server geri tərcümə edir. Ona görə cihazlar və NAT əsaslı uzaq giriş rolları belə davranır.

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

Qiymət aidiyyətdir: hər müştəri üçün ünvanlar LAN jurnallarından itir. LAN hostundakı hər icazə siyahısı o zaman hovuzu deyil, serveri adlandırmalıdır.

Tərcüməni əməkdaşlıq əlçatan olmayanda seçin, sadəcə narahat olanda deyil. O, müştərini hər gələcək araşdırmadan gizlədir, o cümlədən hansı noutbukun bağlantı açdığını bilməli olduğunuz hallardan. O, ünvanları faydalı yükə yerləşdirən protokolları da poza bilər, çünki tərcümə başlıqda yaşayır. Heç bir variant daha irəli deyil; onlar mülkiyyət barədə fərqli suallara cavab verir.

Üçüncü sual: serverin özü başqa tunelin müştərisidirmi?

Digər topologiyanı təsəvvür edin: VPN serveri həm də kommersiya provayderinə zəng edir, yəni iki tuneli və iki ünvan dəsti var. Öz müştəriləri üçün yönləndirdiyi trafik provayderdən çıxır və o, cavabları hovuz ünvanlarına geri yönləndirməyəcək. Ona görə hər iki tunel sağlam olsa da cavablar yox olur.

Həll çıxan tuneli də maskalamaqdır ki, provayder yalnız serverin tunel ünvanını görsün. Əks istiqamətin öz qaydası lazımdır, çünki serverin öz müştərisinə bağlantı başlatması başqa axındır. Bu qayda olmadan müştəri marşrutlaşdıra bilmədiyi ünvana cavab verir. Dar qaydayı hər geniş maskalamadan əvvəl qoyun ki, konkret tərcümə qalib gəlsin.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Çox interfeysli hostlar müştəri tərəfindən eyni görünən əlaqəli nasazlıq əlavə edir. Cavab daha aşağı metrikalı interfeysdən çıxır, çünki mənbə ünvanı başqa cədvəldən seçilib. Geri yolunu axtarışla yoxlayın, irəli yolun onu nəzərdə tutduğunu güman etməyin.

Sonra hər iki istiqaməti və hər iki ölçünü yoxlayın

Dəyişiklikdən sonra müştəridən LAN hostuna, sonra LAN hostundan müştəriyə ping edin. İkinci istiqamət insanların atladığı istiqamətdir və natamam tərcümə qaydasını məhz o üzə çıxarır. Hər iki nəticəni vaxt damğası ilə qeyd edin ki, sonrakı reqressiya müqayisə oluna bilsin.

Sonra real məlumat köçürün, çünki böyük ötürmə dayanarkən uğurlu olan kiçik ping MTU simptomudur. Bu nasazlıq marşrutu düzəltdiyinizə görə özünüzü təbrik etdikdən dərhal sonra görünür.

Nəhayət, yenidən başlatmadan sonra yenidən yoxlayın. İşləmə vaxtı marşrut və firewall əmrləri onu keçmir və növbəti başlatmada yox olan düzəliş daha az konteksti olan biri tərəfindən yenidən diaqnoz ediləcək. Dəyişikliyi sisteminizin artıq etdiyi kimi davamlı edin, sonra bir dəfə qəsdən yenidən başladın.