OpenVPN-ə qoşulub, amma heç nə yüklənmir: müştəri tərəfdən yürüş

Müştəri pəncərəsində Connected yazır, tunel ünvanı yerindədir, brauzer isə hələ də fırlanır. Bu birləşmə normaldır, çünki uğurlu əl sıxma yalnız tunelin qurulduğunu sübut edir; paketlərinizin server tərəfindən yönləndiriləcəyini, mənbəyinin yenidən yazılacağını və ya DNS sorğularınızın cavablandırılacağını demir. Çoxlarının etdiyi səhv ilk olaraq server konfiqurasiyasını açmaqdır. Əvəzində müştəridən çölə doğru işləyin, çünki aşağıdakı hər addım növbəti addımın ümumiyyətlə yoxlanmağa dəyər olub-olmadığını deyir.

Müştəridən başlayın və çölə doğru gedin

Üç testi bu ardıcıllıqla aparın və birincinin harada uğursuz olduğunu yazın. Serverin tunel ünvanına ping göndərin; bu, tunelin özünün trafik daşıdığını sübut edir. Ümumi ünvana rəqəmlə ping göndərin; bu, ad həllini işə qatmadan yönləndirməni və çevrilməni sübut edir. Sonra host adını həll etməyə çalışın; bu, DNS-i işə salan yeganə testdir. Hər nəticə bir bütöv təbəqəni şübhədən çıxarır.

Brauzer daha sürətli görünür deyə üçüncü testə keçməyin. Uğursuz səhifə yükləməsi hər üç təbəqəni eyni vaxtda əhatə edir və oradan başlamaq insanların işlək tuneli yenidən qurmasına gətirib çıxarır. Uğursuz səhifə üçündən hansının sındığını demir.

İki tutma paketlərin harada dayandığını göstərir

Müştəridən ümumi ünvana ping işləyərkən tunel interfeysində bir, internetə çıxmalı olan yuxarı kanalda isə başqa bir tutma götürün. Hər ikisini eyni vaxtda işlədin ki, zaman nişanları üst-üstə düşsün.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Əgər sorğular tuneldə görünür və yuxarı kanalda heç görünmürsə, server onları tunel ilə naqil arasında atıb və səbəb NAT deyil, yönləndirmə və ya yönləndirmə qoruyucu divar siyasətidir. Əgər hər ikisində görünürsə, server öz hissəsini edib və cavab daha uzaqda itib; bu, çevrilməyə, yuxarı axın filtrinə və ya provayder tərəfindən məhdudiyyətə işarə edir.

Yuxarı kanalın adını dərslikdən deyil, marşrut cədvəlindən götürün. Bulud obrazları və adı dəyişdirilmiş adapterlər bələdçidəki nümunə interfeyslə nadir hallarda üst-üstə düşür və yanlış cihazda götürülmüş tutma yönləndirmə etməyən serverə tam bənzəyir:

ip -4 route get 9.9.9.9

Bu çıxışdakı dev sahəsi NAT qaydasının sonra ehtiyac duyacağı addır, ona görə onu saxlayın.

Yönləndirmə bir nüvə açarı və bir qoruyucu divar siyasətidir

Nüvə ümumiyyətlə yönləndirməyə razı olmalıdır. Cari dəyəri oxuyun, sonra parametri yalnız işləyən nüvəyə yazmaq əvəzinə daimi edin:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Yönləndirmə işin yalnız yarısıdır. UFW istifadə edən hostda yönləndirmə siyasəti /etc/default/ufw faylında qurulur və yenidən yükləmə qüvvəyə minməzdən əvvəl ACCEPT olmalıdır. Yönləndirmə yolunda susmaya görə buraxma əl sıxmanı tam sağlam saxlayır, amma tuneldən çıxmağa çalışan hər paketi səssizcə atır — başladığınız simptom məhz budur.

nftables-i birbaşa idarə edən hostlar eyni sualla fərqli sintaksisdə üzləşir. Müştəri testi işləyərkən yönləndirmə zəncirindəki sayğacları yoxlayın, çünki müraciət edilən zəncir ilə atan zəncir konfiqurasiya faylında eyni görünür.

NAT qaydasında əsl çıxış interfeysini adlandırın

Mənbə çevrilməsi hostdan həqiqətən çıxan interfeysə və serverin payladığı hovuza aid olmalıdır. Qaydanın hər iki yarısı reallığı təsvir etməlidir və heç biri isteğe bağlı deyil.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Klassik uğursuzluq bələdçidən kopyalanmış və adapteri başqa adla çağırılan maşında -o eth0 deyən qaydadır. Qayda xəbərdarlıq olmadan quraşdırılır, heç nəyə uyğun gəlmir və müştəri yenə internetsiz qalır. Hovuz da eyni səhvin digər yarısıdır: server 10.44.0.0/24 yayımlayırsa və qayda 10.8.0.0/24 əhatə edirsə, heç vaxt heç nə uyğun gəlməyəcək.

Qayda mətninə güvənmək əvəzinə sayğaclara baxın. Siyahı hər qayda üzrə paketləri göstərir və heç vaxt uyğun gəlməyən qayda nə qədər düzgün görünsə də sıfırda qalır. Bu rəqəmdən nəticə çıxarmazdan əvvəl ona bir dəqiqəlik real müştəri trafiki verin:

iptables -t nat -L POSTROUTING -v -n

Real müştəri testindən sonra sıfır paket sayı tunelin sındığını deyil, uyğunlaşmanın səhv olduğunu bildirir. Uyğunlaşma başlayandan sonra qayda dəstini yadda saxlayın ki, yenidən başlatmaya dözüm etsin; yalnız shell tarixçəsində yaşayan düzəliş ilk yenidən başlatmada yox olur.

Server həm də bulud NAT instansıdırsa, platformanın da sözü var. Ünvanları çevirən instans adətən provayderin təqdim etdiyi yerdə mənbə və təyinat yoxlamasının söndürülməsini tələb edir, VPN portunun özü isə xaricdən əlçatan olmalıdır.

DNS birincinin arxasındakı ikinci uğursuzluqdur

Ünvanla ping işləyərkən adların uğursuz olması həlledici ilə bağlı problemdir, və onun öz səbəbi var. Lokal həlledicisini saxlayan müştəri bu sorğuları tam tunelə göndərir və heç vaxt gəlməyən cavabı gözləyir, çünki lokal həlledici artıq marşrutun səhv tərəfindədir.

Müştərinin hara soruşacağını bilməsi üçün serverdən həlledici göndərin. İki giriş, birincisi əlçatmaz olduqda müştəriyə ehtiyat variant verir və hər ikisi tunelin həqiqətən icazə verdiyi həlledicilər olmalıdır.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows müştəriləri sonra yenə lokal həllediciyə düşə bilər; block-outside-dns məhz bunun qarşısını almaq üçün mövcuddur, amma bunun qiyməti yalnız lokal şəbəkənin həll edə bildiyi adları itirməkdir. systemd-resolved istifadə edən Linux müştəriləri çox vaxt göndərilmiş həlledicini skript onu quraşdırmasa nəzərə almır, ona görə göndərişin nəzərə alınmadığı qənaətinə gəlməzdən əvvəl tunel cihazı üçün resolvectl status yoxlayın.

Yürüşü istifadəçinin yaşadığı kimi tamamlayın. Müştəridən real səhifə yükləyin, hansı ünvandan çıxdığını təsdiqləyin, serveri yenidən başladın, yenidən qoşulun və üç testi təkrarlayın. Yalnız bu ikinci gediş saxlanılan qaydaların, qoruyucu divar siyasətinin və göndərilmiş həlledicinin birlikdə qaldığını sübut edir.