PiVPN əl sıxışması işləyir, səhifələr donur: MASQUERADE-i yoxlayın

Telefonunuz tuneli qoşulmuş kimi göstərir, müştəri özəl ünvan bildirir, amma ilk səhifə hələ də yüklənmənin ortasında donur. Bu birləşmə insanların çoxunu şifrə ayarlarına və prosessor temperaturuna yönəldir, halbuki əslində heç nə səhv deyil. Tunel qalxdı, yəni razılaşma bitdi; uğursuz olan ondan sonrakı addımdır, server müştəri paketlərini internetə ötürməyə çalışanda. Həmin paketlərin getdiyi yolu izləyin və uyğunsuzluq adətən NAT cədvəlinin bir sətrində görünür.

Müştərinin nəyə çata bildiyindən və nəyə çata bilmədiyindən başlayın

Qoşulmuş müştəridən açıq internetdə yerləşən səhifəni yükləyin və onun dərhal uğursuz olduğunu, yoxsa yarıda donduğunu qeyd edin. Sonra VPN serverinin öz özəl ünvanındakı resursu açın və iki nəticəni müqayisə edin.

Ping sorğularına cavab verən, amma açıq saytların vaxtı bitən tunel ünvanı yönləndirmə və ya çevirmə probleminin əlamətidir, qırılmış əl sıxışma deyil. Müştərinin öz status paneli bunları ayırd edə bilmir, çünki o yalnız idarə kanalının açıq olduğunu bilir. Serverdə tunel interfeysini bununla yoxlayın: ip -br addr show tun0 və müştəriyə verilən ünvanın konfiqurasiya etdiyiniz hovuzun içində olduğunu təsdiqləyin. Hovuzla müştəri ünvanı uyğun gəlmirsə, əvvəlcə onu düzəldin, çünki aşağıdakı hər qayda hovuza uyğunlaşır.

Sonra serverdən açıq ünvana hansı interfeyslə gedəcəyini soruşun. ip route get 203.0.113.9 ilk sətrində seçilmiş cihazı və mənbəni çap edir. Bu cihaz adını yazın, çünki NAT qaydasında məhz bu dəyər olmalıdır.

Paketlərin çıxıb-çıxmadığını həll edən qaydayı oxuyun

MASQUERADE paketi yalnız qaydada göstərilən interfeysdən çıxdıqda yenidən yazır. Simli cihaza bağlanmış qayda Wi-Fi ilə çıxan trafik üçün heç nə etmir və paket yuxarı marşrutlaşdırıcıya qədər özəl mənbə ünvanını saxlayır. Həmin marşrutlaşdırıcının tunel hovuzunuza geri dönüş marşrutu yoxdur, ona görə cavabı atır və müştəri açılıb sonra ölən bir əlaqə görür. Simptom səhifənin ilk cavab lazım olana qədər nə qədərinin gəldiyindən asılıdır.

Canlı cədvəli siyahıya alın və sadəcə MASQUERADE sözünü axtarmaq əvəzinə çıxış interfeysi sütununu oxuyun. Əlavə formasının çıxışı formatlanmış siyahıdan müqayisə etmək daha asandır:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Əvvəllər Ethernet, indi isə Wi-Fi istifadə edən Raspberry Pi-də köhnə ad demək olar ki, bütün hekayədir. Quraşdırıcı quraşdırma zamanı hansı cihazın olduğunu qeyd edib və saxlanılan qayda dəsti hər açılışda onu təkrar oxudur. Başqa bir şeyi dəyişməzdən əvvəl marşrut axtarışından çıxan cihazı qaydadakı ilə müqayisə edin. Onlar uyğun gəlirsə, interfeys sizin probleminiz deyil və son bölmədəki sayğaclara keçin. Fərqlənirlərsə, düzəliş davamlılıq faylında bir sözlük dəyişiklikdir.

Saxlanılan qayda dəstini düzəldin, yalnız işləyənini deyil

Yalnız canlı cədvəli redaktə etmək növbəti yenidən başladılmaya qədər davam edir, bu da problemin həll olunduğuna sizi inandırmaq üçün tam kifayət qədər uzundur. Açılışda qaytarılan qaydalar firewall davamlılıq paketinin yenidən yüklədiyi faylda yaşayır. Debian əsaslı Pi obrazlarında bu fayl adətən /etc/iptables/rules.v4.

Ona toxunmazdan əvvəl surət çıxarın, sonra MASQUERADE sətrindəki çıxış interfeysini qeyd etdiyiniz cihazla dəyişin, məsələn -o wlan0 əvəzinə -o eth0. Müştəri hovuzunuz dəyişməyibsə, mənbə diapazonunu olduğu kimi saxlayın. Yenidən yükləyin və qaydanın indi düzgün cihazı göstərdiyini təsdiqləyin:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

İki qonşu ayarı unutmaq asandır. sysctl net.ipv4.ip_forward 1 göstərməlidir və yuxarı marşrutlaşdırıcı özəl mənbə ünvanlarını özü filtrləməməlidir.

Qaydanın işə düşdüyünü sübut edin, sonra hələ nəyin yavaş olduğunu təcrid edin

Sayğaclar qaydanın uyğunlaşdığının yeganə dürüst sübutudur. Geniş siyahını işə salın, müştəridə yükləməyə başlayın və yenidən işə salın. Qaydanızın yanındakı paket və bayt sütunları artmalıdır və sıfırda qalan qayda hələ də uyğunlaşmır. Sayğaclar hərəkət edir, amma səhifələr yenə də uğursuz olursa, mənbə diapazonunu faktiki hovuzla bununla müqayisə edin grep -n "^server " /etc/openvpn/server.conf. Sayğaclar hərəkət edib səhifələr açılırsa, amma ötürmə qabiliyyəti zəifdirsə, çevirmə bitib və qalan problem başqa yerdədir.

Eyni müştəridən iki ötürməni müqayisə edin, biri yerli şəbəkədəki hosta, biri tuneldən həmin hosta. Hər iki halda yavaşlıq VPN-ə deyil, Pi-nin yuxarı kanalına və ya Wi-Fi bağlantısına işarə edir. Yalnız tuneldən yavaşlıq MTU və yenidən ötürmələrə işarə edir, bunları bununla yoxlaya bilərsiniz ip -s link show tun0 hər hansı kripto ayarını dəyişməzdən əvvəl.

Təcrübəni geri qaytarmaq üçün surəti bərpa edin və yenidən yükləyin, sonra orijinal qaydanın və sayğaclarının geri qayıtdığını təsdiqləyin. Çıxış cihazını və yenidən yükləmə əmrini server qeydlərinə yazın, çünki növbəti yuxarı kanal dəyişikliyi eyni uyğunsuzluğu yenidən kəşf edəcək. Səhv cihazı göstərən qayda trafik ona ehtiyac duyana qədər görünməz qalır.