VPN müştəriləri qoşulur, amma internet yoxdur: üç çatışmayan parça

Müştəri ünvan alır, server ping-lərə cavab verir və buna baxmayaraq hər səhifə vaxt aşımına düşür. Çox adam bu məqamda müştəri profilini redaktə etməyə başlayır, bu isə adətən boşa səydir: tunel qalxdıqdan sonra server özünü marşrutlaşdırıcı kimi aparmalıdır. Paket çıxıb cavab qayıtmazdan əvvəl üç şərt eyni vaxtda ödənməlidir və hansı çatışmırsa, simptom eynidir.

Niyə işləyən tunelin hələ də çıxış yolu yoxdur

Nüvə paketləri interfeyslər arasında yönləndirməlidir, bu isə əksər Linux paylamalarında susmaya görə söndürülmüşdür. Trafik xarici dünyanın cavab verə biləcəyi ünvana tərcümə olunmalıdır, məgər hər yuxarı axın marşrutlaşdırıcısı artıq tunel alt şəbəkəsinə geri dönüş yolunu bilirsə. Firewall-un yönləndirmə yolu trafiki hər iki istiqamətdə, cavablar da daxil olmaqla, keçirməlidir.

Bunların hər biri ayrıca düzəldilə bilər, tələ isə elə budur. Tərcümə qaydası olmadan yönləndirməni açmaq paketlərin şəxsi mənbə ilə çıxmasına və geri dönüş yolu olmamasına gətirib çıxarır. Yönləndirmə qaydası olmadan tərcümə əlavə etmək nüvənin paketi bir addım sonra atmasına səbəb olur.

Yəni müştərini deyil, üç qatı sınaqdan keçirin və nəticənin mənası olsun deyə hər dəfə birini dəyişin.

Yönləndirmə davamlı etməli olduğunuz nüvə açarıdır

Dəyişməzdən əvvəl cari dəyəri yoxlayın, sonra onu təyin edin və dəyişikliyin qüvvəyə mindiyini təsdiqləyin.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Birinci əmr cari dəyəri göstərir, ikincisi onu işləmə vaxtında təyin edir, üçüncüsü isə yazmanın işlədiyini sübut edir. İşləmə vaxtı dəyəri növbəti yenidən başlatmada yox olur, buna görə də işləyən sessiya heç bir konfiqurasiya dəyişikliyi olmadan texniki xidmətdən sonra poza bilər.

Onu /etc/sysctl.d/ altındakı faylda davamlı edin, sonra nəticəni öyrənmək üçün yenidən başlatmaq əvəzinə həmin faylı tətbiq edin. FreeBSD-də ekvivalent net.inet.ip.forwarding-dir və davamlılıq üçün rc.conf faylında gateway_enable=YES yazılır. Yönləndirmənin söndürüldüyünü bildirən cihaz «paketlər gəlir, heç nə qayıtmır» tipli hesabatların bütöv bir sinfini izah edir. Hər yeniləmədən sonra da parametri yoxlayın, çünki yenidən qurulmuş nüvə və ya dəyişdirilmiş cihaz obrazı heç kimə demədən onu sıfırlaya bilər.

Masquerade və ya bir sabit tərcümə ünvanı seçin

Dinamik xarici ünvanla masquerading ən sadə düzgün formadır. Mənbə kimi tunel alt şəbəkəsini, çıxış kimi isə xarici interfeysi göstərin.

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

Statik ictimai ünvanla mənbənin məhz həmin ünvana tərcüməsi daha proqnozlaşdırıla biləndir və audit etmək daha asandır.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

İkinci formanın özündə texniki xidmət tələsi var: sonradan dəyişən sərt kodlanmış ünvan tuneli işlək saxlayır, internet çıxışı isə səssizcə dayanır. Ya masquerade işlədin, ya da provayder sizi köçürəndə qaydanı yeniləyin. İnterfeys də önəmlidir, çünki öz yuxarı axın tunelini paylaşan marşrutlaşdırıcı fiziki WAN-dan deyil, həmin tuneldən tərcümə etməlidir.

Filtr cədvəli üçüncü darvazadır

Yönləndirmə də, tərcümə də düzgün ola bilər, paket yenə də filtr cədvəlində ölə bilər. ufw tez-tez günahkardır: onun yönləndirmə siyasəti DROP kimi gəlir və qalan quruluş tam düzgün görünə bilər, halbuki həmin bir parametr trafiki öldürür. Onu qaldırmaq qeyd xanası deyil, şüurlu təhlükəsizlik qərarıdır.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Birinci qayda tuneldən xaricə doğru yeni trafikə icazə verir, ikincisi isə yalnız cavabların geri qayıtmasına. Hər ikisini tunel alt şəbəkəsi və nəzərdə tutduğunuz təyinatla daraldın, çünki tunel interfeysində ümumi icazə VPN-i autentifikasiyadan keçən hər kəs üçün açıq çıxış nöqtəsinə çevirir.

Körpülənmiş tunel başqa cavab tələb edir. Ünvan fiziki porta deyil, körpüyə aiddir, ona görə interfeysi körpüyə qoşmaq onun əvvəl daşıdığı ünvanı silir və körpünün özü ünvan alana qədər host əlçatmaz görünür; bu ünvanı dhclient br0 verə bilər. Bu nasazlıq VPN problemi kimi görünür, əslində isə ikinci qat problemidir. Firewall-a toxunmazdan əvvəl körpünün öz ünvanını yoxlayın, çünki filtr dəyişikliyi artıq göndərmə ünvanı olmayan hostu düzəldə bilməz.

Səhifə heç yüklənməyəndə hara baxmalı

Tunelin mövcudluğunu sübut etmək üçün serverin tunel ünvanına ping göndərin. Sonra müştəridən ictimai ünvana traceroute işlədin və harada dayandığını oxuyun: serverdə paket gəlir, lakin yönləndirilmir və ya tərcümə olunmur; serverdən o yanda problem yuxarı axındadır və sizin əlinizdə deyil.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Birinci əmr tunelin trafiki serverin özünə apardığını sübut edir, ikincisi isə paketin xaricə nə qədər getdiyini göstərir. Tunel ünvanında bitən iz serverdə yönləndirməyə və ya tərcüməyə işarə edir, bir addım sonra dayanan iz isə provayderə və ya yuxarı axın marşrutlaşdırıcısının geri dönüş yoluna.

Serverdə müştəri səhifə yükləyərkən xarici interfeysi izləyin. Şəxsi mənbə ünvanı ilə çıxan trafik tərcümənin çatışmadığını, heç bir cavabın olmaması isə yönləndirmə yolunun və ya yuxarı axın geri dönüş marşrutunun onu atdığını göstərir.

Uzaq müştərilər serverin yerli şəbəkəsindəki hostlara da çatmalıdırsa, yadda saxlayın ki, yerli şəbəkəyə tunel alt şəbəkəsinə geri dönüş marşrutu lazımdır. Bu tərcümə deyil, marşrutlaşdırmadır və internet yolu nəhayət işləyəndən sonra ən çox unudulan addımdır.