OpenVPN müştərisinin arxasındakı alt şəbəkə niyə əlçatmazdır?

Serverin tunel ünvanına pinglər keçir, müştərinin öz marşrut cədvəli düzgün görünür, amma həmin müştərinin arxasındakı LAN hələ də əlçatmazdır. Müştərinin marşrut cədvəli doğru görünür, serverdə tunelə istiqamətlənən marşrut var, paketlər yenə də yox olur. Bu, müştərilərindən birinin eyni zamanda şlüz olduğunu bilməyən layer-3 tunelinin klassik simptomudur.

tun interfeysinin hər müştəri üçün növbəti atlama nöqtəsi yoxdur. Nüvə çox sayda həmkarı olan bir interfeys görür, ona görə uzaq LAN üçün paketi hansı müştərinin alacağı qərarı OpenVPN prosesinin içində verilməlidir. Bu qərar iroute ilə qurulur və onsuz paketin gedəcəyi yer yoxdur.

Server interfeysə görə deyil, müştəriyə görə marşrutlaşdırır

Server müştərinin tunel ünvanına paket göndərməlidirsə, cavab birmənalıdır: ünvan həmin müştərinin sessiyasına aiddir. Hədəf həmin müştərinin arxasındakı bütöv alt şəbəkədirsə, ünvan serverin tanıdığı heç kimə aid deyil və nüvənin tunelə marşrutu yalnız "bu interfeysdən çıx" deyir, hansı həmkar olduğunu demir.

OpenVPN bunu hədəf prefiksini müəyyən müştəriyə bağlayan daxili marşrut cədvəli ilə həll edir. Bu cədvəl iroute sətirlərindən qurulur, buna görə server hostunda adi marşrut kifayət etmir. Nüvə marşrutu paketi tunel interfeysinə çatdırır; hansı sessiyanın onu alacağını daxili əlaqələndirmə qərar verir. Buna görə də düzəliş heç vaxt nüvənin marşrut çıxışında görünmür.

Əgər əlaqələndirmə yoxdursa, paket serverə çatır, tunel marşrutuna uyğun gəlir və heç bir müştəri hədəfi tələb etmədiyi üçün atılır. Heç nə təmiz xəta qeyd etmir, buna görə nasazlıq marşrut dövrəsi kimi deyil, sakit qara dəlik kimi görünür.

Müştərini adlandıran iroute sətrinin yazılması

iroute əsas server konfiqurasiyasında deyil, müştəriyə xas konfiqurasiya faylında yaşayır. Serveri client-config-dir seçimi ilə bir qovluğa yönləndirin, sonra adı müştərinin sertifikatının ümumi adı olan fayl yaradın və prefiksi içərisinə yerləşdirin.

LAN-ı 10.20.0.0/24 olan və sertifikatının ümumi adı branch-router olan filial üçün həmin yoldakı fayl iroute 10.20.0.0 255.255.255.0 kimi bir sətir saxlayır. Əsas konfiqurasiyaya yalnız qovluq seçimi lazımdır; prefiks müştərinin yanında yaşayır.

Ümumi ad həssas hissədir. Fərqli subyektlə verilmiş sertifikat və ya istifadəçiləri istifadəçi adı ilə doğrulayan, amma faylı sertifikata görə adlandıran quraşdırma heç vaxt oxunmayan fayl yaradır. Serverin sessiya üçün həqiqətən bildirdiyi adı yoxlayın və uyğunsuz müştərinin marşrutsuz səssizcə qoşulması əvəzinə uğursuz olmasını təmin edən seçimi nəzərdən keçirin. Faylı sertifikata uyğun adlandırmaq çox uzun bir axşamın qarşısını alan beş dəqiqəlik düzəlişdir.

Bir müştəri bir neçə prefiksə sahib ola bilər. Hər şəbəkə üçün bir iroute sətri əlavə edin və əlaqələndirmənin yoxlanıla bilən qalması üçün siyahını həmin müştərinin digər parametrlərinin yanında saxlayın.

Geri yolun hər iki istiqamətdə qurulması

Paketləri uzaq LAN-a çatdırmaq işin yarısıdır. Müştəri də həmin LAN-ın trafikini tunelə göndərməlidir və bu adətən müştəriyə marşrut itələməklə edilir: push "route 10.8.0.0 255.255.255.0" kimi bir sətir hər müştəriyə server tərəfindəki şəbəkəyə necə çatacağını deyir. Filial üçün ekvivalent marşrut server tərəfində çatmalı olduğu hər şey üçün tunelə işarə edir.

Geri istiqamətin uzaq tərəfdə sahibi olmalıdır. Həmin tərəfdə kimsə geri yolu bilməlidir: LAN marşrutlaşdırıcısında VPN hovuzunu serverə yönəldən statik marşrut və ya trafik LAN-a girməzdən əvvəl serverdə ünvan çevirməsi. Statik marşrut orijinal ünvanları qeydlərdə və giriş qaydalarında görünən saxlayır, amma LAN sahibinin əməkdaşlığını tələb edir; çevirmə özünü təmin edir, lakin kimin həqiqətən qoşulduğunu gizlədir.

Server hostunda yönləndirmə aktiv olmalıdır. Olmadan nüvə paketi tuneldən qəbul edir və LAN interfeysinə ötürməkdən imtina edir, bu da müştərinin baxışından çatışmayan iroute ilə eyni görünür.

Əlçatanlığın düzgün zondlarla yoxlanması

Uzaq ucu ping edib təxmin etmək əvəzinə qat-qat test edin. Serverdən prefiks üçün daxili əlaqələndirmənin olduğunu və nüvə marşrutunun tunelə işarə etdiyini yoxlayın. Müştəridən itələnmiş marşrutun quraşdırıldığını və LAN ünvanı üçün standart yolunun tunel olduğunu təsdiqləyin.

Sonra paketləri izləyin. Tunel interfeysində tutma serverin müştəriyə doğru ötürüb-ötürmədiyini, LAN interfeysində tutma isə yönləndirib-yönləndirmədiyini göstərir. Birincisi paket göstərir, ikincisi heç nə göstərmirsə, problem yönləndirmə və ya filtrlədir; heç biri heç nə göstərmirsə, axtarış daha əvvəl uğursuz olub.

Tunellə birləşən iki server hər iki tərəfdə eyni qaydayı təkrarlayır: hər birinə digərinin hovuzu üçün iroute, həm də yolu simmetrik edən marşrut və yönləndirmə lazımdır. Burada marşrutlaşdırma və siyasət ayrı məsələlərdir. Marşrutlaşdırma paketin hara gedə biləcəyini, FORWARD qaydası isə buna icazə olub-olmadığını qərar verir, ona görə iki iroute sətri olan müştəri filtr başqa cür deməzsə hər iki prefiksə çata bilər.