OpenVPN köhnə marşrutları göndərməyə davam edir? Onun nə yüklədiyinə baxın

Bir marşrut göndərişi əlavə edir, xidməti yenidən başladır, yenidən qoşulursunuz, müştərinin cədvəli isə yenə əvvəlki kimidir. İki fərqli şey doğru ola bilər: ya server sizin düzəlişinizi yükləməyib, ya da müştəri aldığını quraşdırmayıb. Simptomdan başqa bunların ortaq heç nəyi yoxdur, ona görə də ilk addım hansı vəziyyətdə olduğunuzu öyrənməkdir.

Aşağıdakı müqayisə prosesdən bayıra doğru gedir, çünki hansı faylın qüvvədə olduğunu yalnız proses müəyyən edir.

Redaktə etdiyiniz fayl və prosesin oxuduğu fayl

Vahidlə və onun yaratdığı əmr sətri ilə başlayın. systemd hostunda systemctl cat openvpn@server ExecStart sətrini çap edir, instans vahidi isə adətən konfiqurasiya yolunu instans adından götürür, yəni openvpn@office kimi başladılan demon openvpn@server kimi başladılandan fərqli fayl oxuyur. Bunu işləyən prosesin argv-si ilə tutuşdurun. Konfiqurasiya idarəetmə aləti dəyişikliyi itirməyin başqa bir yolunu əlavə edir: düzgün faylı vahidin heç vaxt qeyd etmədiyi yerə yaza bilər və bu, yaşıl bir deploy-u heç bir nəticə verməyən kimi göstərir.

Zaman nişanları bunu tez həll edir: fayl prosesin başlama vaxtından yenidirsə, proses onu oxuya bilməzdi. Router proqram təminatı üçüncü halı əlavə edir, çünki bir çox model ayarlarını flash yaddaşında saxlayır və yükləmə zamanı konfiqurasiyanı yenidən qurur, bu da diskdəki fayl redaktəsini tamamilə yanlış qata çevirir.

Server nə göndərir, müştəri nə quraşdırır

Göndərilən marşrut iki süzgəcdən keçməlidir. Serverdə o, yüklənmiş konfiqurasiyada olmalıdır, şərh blokunda və ya adı uyğun gəlməyən müştəriyə xas faylda deyil. Müştəridə isə pull aktiv olmalı və heç bir pull-filter seçimi atmamalıdır. verbosity 4 ilə qoşulun və müştərinin bildirdiyi göndərilmiş seçimləri oxuyun: marşrut həmin siyahıda görünürsə, server öz işini görüb, onu quraşdırmamağı müştəri seçir.

Müştəriyə xas fayllar tez-tez çaşqınlıq mənbəyidir. Sertifikatın common name-i ilə adlandırılmış fayl seçimləri yalnız həmin müştəriyə göndərir və bir simvolluq uyğunsuzluq göndərişi səssizcə dayandırır, heç bir tərəfdə xəta görünmür. Server qoşulma anında gördüyü common name-i jurnala yazır, ona görə də bu dəyəri fayl adı ilə tutuşdurun, müştərinin adının nə olduğunu düşündüyünüzlə deyil.

Göndərilən prefiks və qayıdış marşrutu fərqli problemlərdir

Yerli internet yolunu saxlamaq üçün redirect-gateway-i qəsdən nəzərə almayan müştəri ikinci, əlaqəsiz bir boşluq yaradır. Serverin yoxlamaları tunel ünvanına çatır, cavablar isə heç vaxt gəlmir, çünki serverin tunel IP-sinə ünvanlanmış cavab müştərinin adi defolt şlüzü ilə yönləndirilir. Burada günah göndərilən subnet marşrutunda deyil; çatışmayan şey serverin tunel şəbəkəsi üçün trafiki yenidən tunel qurğusuna göndərən marşrutdur.

Bu marşrutu müştəridə əlavə etmək serverin başlatdığı yoxlamalara verilən cavabları düzəldir. O, göndərilən subnet marşrutunu əvəz etmir və əksi də doğrudur, çünki ikisi hərəkətin əks istiqamətlərini təsvir edir.

Hər iki tərəfdə cədvəlləri tutuşdurun

Hər hansı dəyişiklikdən sonra yenidən qoşulun və müştərinin cədvəlində göndərilən prefiksi və tunel qurğusunu oxuyun. Sonra hər iki istiqamətdə sınayın: müştəridən göndərilən subnetdəki hosta, sonra həmin hostdan müştəriyə. Mövcud olub heç bir trafik daşımayan marşrut üç şeydən birini bildirir: uzaq tərəf yönləndirmir, firewall axını atır, ya da cavabın qayıtmağa yolu yoxdur.

Üç identifikatoru birlikdə saxlayın: konfiqurasiya yolu, vahid və ya instans adı, və sınaq üçün istifadə etdiyiniz müştəri kimliyi.

Bu üçü növbəti hadisəni təkrar araşdırma yerinə beş dəqiqəlik yoxlamaya çevirir və tunel başqasının problemi olanda həmkarınıza lazım olan da elə budur.

Yenidən başlatmadan sonra da qalan marşrut problemi çox vaxt heç marşrut problemi deyil; nasazlıq davamlı oxuduğunuz cədvəlin yuxarısındadır.