VPN portunu açmaq müştəriləri LAN-a çıxarmır

Tunel qalxır, müştəri autentifikasiyadan keçir, amma şlüzün arxasındakı LAN görünməz qalır. Bunu düzəltməli olan qayda VPN portuna icazə verir və yazıldığı kimi işləyir, çünki həmin qayda şlüzün özünə ünvanlanan paketləri tənzimləyir. Şlüzün arxasındakı hosta gedən müştəri trafiki başqa təyinat və başqa zəncirdir. Uğurlu giriş nüvənin hansı zəncirə baxdığını dəyişmir.

İki zəncir, iki fərqli təyinat

Paketin taleyi hara getdiyi ilə müəyyən olunur, necə gəldiyi ilə deyil. Şlüzün ünvanına göndərilən trafik yerli olaraq çatdırılır və giriş qaydalarına uyğun qiymətləndirilir. Şlüzün irəli ötürdüyü trafik isə yönləndirmə qaydalarına uyğun qiymətləndirilir. Eyni tunel interfeysi hər iki növ paketi yarada bilər, buna görə bir qayda hər iki işi əhatə edə bilməz.

Bütün mif bir cümlədə budur: dinləyiciyə icazə vermək onun arxasındakı şəbəkəyə icazə vermək barədə heç nə demir. Bunlar ayrı-ayrı sübutlara malik iki ayrı qərardır və hər ikisində interfeys adının olması onları birləşdirmir.

Dinləyici qaydası əslində nəyə icazə verir

Dinləyici paketləri VPN prosesində bitir və tunelin ümumiyyətlə qurulmasına məhz bu imkan verir. Şlüzün idarəetmə səhifəsi və yerli diaqnostik cavab da hostun öz giriş yolundan istifadə edir, buna görə şlüzə edilən yoxlama uğurlu olur, arxasındakı hər şey isə uğursuzluğa düşür. Hər iki nəticə düzgündür və heç biri LAN barədə deyil.

Proses müştəri trafikini başqa təyinat üçün dekapsulyasiya etdikdən sonra paket yönləndirmə yoluna daxil olur və orada icazə tələb edir. Autentifikasiyanın uğurlu olması müştərinin kim olduğunu həll edir; hara gedə biləcəyini həll etmir. İki sualın fərqli sahibləri, fərqli jurnalları və fərqli xəta mesajları var.

Müştəridən sınaqdan keçirin, heç vaxt şlüzdən

Şlüzdə yaradılan sınaq hostun öz çıxış yolunu izləyir və yönləndirilən yol bağlı olsa da keçə bilər. Sınağa müştəridən başlayın və axının hər iki ucunu izləyin.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Əgər sorğu tun0 üzərində görünürsə və təyinat yerinə heç nə çatmırsa, paket gəldikdən sonra atılır, bu da yönləndirmə qaydalarına və ya təyinatın öz filtrləməsinə işarə edir. Əgər tun0 üzərində ümumiyyətlə heç nə görünmürsə, müştəri onu tunelə belə göndərmir və problem şlüzdəki siyasətdə deyil, müştəridəki marşrutlaşdırmadadır. Bunu düzgün çıxıb heç nə qaytarmayan sorğu ilə müqayisə edin, bu da geri yol halıdır.

Yönləndirmə bir deyil, üç şey tələb edir

Nüvə yönləndirməsi aktiv olmalı, filtr qaydası axını qəbul etməli və təyinat əlçatan olmalı, cavabın qayıtma yolu da olmalıdır. Üçündən biri yoxdursa, müştəri baxımından sükut eynidir.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Üç çıxışı birlikdə oxuyun. Birincidəki sıfır digər ikisini əhəmiyyətsiz edir, ikincidəki standart imtina siyasəti müştərinin paketlərini atır, şlüzün öz trafiki isə işləməyə davam edir. Üçüncü çıxış dinləyici qaydasının heç vaxt problem olmadığını göstərir.

İki qayda dəstini sənədlərdə ayrı saxlayın

Dinləyici qaydasını və yönləndirilən xidmət qaydasını ayrı sətirlərdə, ayrı sahiblər və səbəblərlə yazın. VPN portu dəyişdikdə və ya yeni xidmət yayımlandıqda bu ayrılıq bir dəyişikliyin digərini səssizcə genişləndirməsinin qarşısını alır.

Hər autentifikasiya olunmuş tərəfdaşı etibarlı LAN üzvü kimi qəbul etmək əvəzinə ehtiyac duyan müştəri aralıqları və xidmətlər üçün dar qaydalar istifadə edin. StrongSwan-ın yönləndirmə qeydləri həmin sərhədin geri marşrut və tərcümə tərəfini təsvir edir, bu da yenə üçüncü qərardır.

Nəhayət, istifadəçi rədd edildikdə qatları düz saxlayın. Əgər sorğu hosta çatırsa və tətbiq hesabı rədd edirsə, tətbiq icazəsini həmin qatda düzəldin; yönləndirməni genişləndirmək fayl paylaşımı üçün etimadnamə verə bilməz və uğurla qoşulan bütün digərləri üçün girişi genişləndirəcək.