OpenVPN DHCP yenilənməsindən sonra qopur: son nöqtə marşrutunu saxlayın

Tunel qoşulur, sonra giriş linkindəki icarə yenilənməsi onu öldürür və jurnal marşrutu deyil, taym-autu günahlandırır. VPN konfiqurasiyasında heç nə dəyişməyib və ipucu da elə budur: ondan kənarda bir şey dəyişib. DHCP hadisəsi ünvanı və ya şlüzü yenidən yazıb və tunelin son nöqtəsini əlçatan saxlayan host marşrutu indi artıq mövcud olmayan növbəti hopa işarə edir. Bu, marşrut problemi olmadan əvvəl sahiblik problemidir.

Simptomu yarımdefolt marşrutlarla müqayisə edin

redirect-gateway def1 ilə OpenVPN defolt marşrutu əvəz etmək əvəzinə 0.0.0.0/1 və 128.0.0.0/1 quraşdırır. Bu ikisi birlikdə bütün ünvan məkanını əhatə edir və yalnız prefiks uzunluğuna görə 0.0.0.0/0-dən üstündür. Ona görə də daha dəqiq uyğunluğu olmayan istənilən təyinat tunelə daxil olur.

Son nöqtəyə istisna lazımdır. OpenVPN yarımdefoltlar qoşulmadan əvvəl orijinal giriş şlüzü vasitəsilə server ünvanına host marşrutu əlavə edir ki, inkapsulyasiya edilmiş paketlər çıxa bilsin. Həmin istisna itəndə və ya artıq mövcud olmayan növbəti hopu saxlayanda tunelin öz xarici paketləri yarımdefolta uyğun gəlir və tunelə geri göndərilir. Nəticə növbəti keepalive və ya əl sıxışmasında ölən bir bağlantıdır və jurnalda marşrut xətasına bənzər heç nə yoxdur.

Başqa heç nəyə toxunmadan cədvəlin formasını təsdiqləyin. ip route show hər iki yarıni üstəlik server ünvanı üçün host marşrutunu göstərməlidir; host marşrutu yoxdursa, araşdırmanın qalanı üçün aydın başlanğıc nöqtəsi var.

Yarımdefoltlar niyə metrika dəyişmədən qalib gəlir

Aşağı metrika daha uzun prefiksi məğlub etmir. /1 marşrutları qalib gəlir, çünki nüvə əvvəlcə ən dəqiq marşruta uyğunlaşdırır, ona görə də defolt marşrutda metrikanı artırmaq tunelə gedən trafikin hara getdiyini heç dəyişmir. Metrikaların arxasınca qaçmaq bu diaqnozda ən çox rast gəlinən səhv dönüşdür.

ip route get 203.0.113.10 ilə seçimi yoxlayın və onu real server ünvanı ilə əvəz edin. Cavab nüvənin həqiqətən istifadə edəcəyi interfeysi və növbəti hopu adlandırır, bu da cədvəli oxuyub üzərində düşünməkdən daha məlumatlıdır.

Bu əmri tunel başlamadan, o işləyərkən və icarə hadisəsindən sonra işə salın. Bir əmrdən üç cavab və ayrılma nöqtəsi görünən olur.

Bir yox, üç snapshot götürün

Giriş ünvanını, giriş şlüzünü, son nöqtə təyinatını, seçilmiş marşrutu və hər hansı siyasət qaydasını üç anda toplayın: giriş linki konfiqurasiya edildikdən sonra, VPN qoşulduqdan sonra və icarə və ya operator hadisəsindən sonra. Hər snapshot bir ovuc əmrdir və onlar yalnız birlikdə məna daşıyır. Uğursuzluqdan sonra bir snapshot keçidi deyil, vəziyyəti qeyd edir. Əmrləri kiçik bir skriptə yazın ki, hər snapshot eyni üsulla götürülsün.

Snapshots tək faylda vaxt nişanları ilə saxlayın, çünki sonra maraqlı sual sıradır. DHCP hadisəsi OpenVPN öz marşrutunu yeniləməmişdən əvvəl, yoxsa sonra gəldi? Cavab bunu kimin düzəltməli olduğunu həll edir. Səhv saatdan götürülmüş vaxt nişanı heç olmamasından pisdir, ona görə onu marşrut cədvəlinə sahib olan hostdan götürün.

Son nöqtə ünvan kimi deyil, ad kimi konfiqurasiya edildiyi halda, onu hər snapshotda da həll edin. Giriş linkindəki DNS dəyişikliyi heç bir marşruta toxunmadan son nöqtəni yerindən tərpədə bilər.

İstisnanı hansı komponentin yenilədiyini qərar verin

dhcpcd sistemində qarmaqlar qarmaq kataloqundan və çıxış qarmağından işləyir, menecer rejimi isə əhatə dairəsinə görə interfeys üzrə rejimdən fərqlənir. Qarmaq nə edirsə, idempotent olmalıdır, çünki yenilənmələr partiyalarla gələ bilər.

Etibarlı sahib hər iki tərəfi artıq bilən inteqrasiyadır: VPN bağlantısını idarə edən şəbəkə meneceri və ya giriş linki qalxdıqdan sonra sıralanan bir unit. Qarmaq tərəfindən əlavə edilən statik marşrut növbəti şlüz dəyişikliyinə qədər işləyir, sonra tam eyni şəkildə uğursuz olur. Əgər qarmaq istifadə edirsinizsə, bugün gördüyünüz şlüzü sərt kodlaşdırmaq yerinə, onu iş vaxtında cari şlüzü oxumağa məcbur edin.

Sahibi konfiqurasiyanın içində qeyd edin. Yenidən qoşulmanı sazlayan növbəti şəxs bilməlidir ki, istisna marşrutuna VPN deyil, qarmaq cavabdehdir.

Yenidən qoşulmanı deyil, həyat dövrünü sınaqdan keçirin

dhcpcd -n eth0 ilə və ya icarəni buraxıb yenidən götürməklə yenilənməyə məcbur edin, sonra son nöqtə üçün ip route get ilə yenidən yoxlayın. Bunu iki dəfə edin, çünki ikinci keçid dublikat marşrutlar əlavə edən qarmaqları tutur. Sonra yenidən başladın, çünki davamlılıq düzgünlükdən fərqli bir xüsusiyyətdir.

Yenilənmədən və yenidən başlatmadan sağ çıxan tunelin sahibi və işlək istisnası var. Yalnız əl ilə yenidən başlatmadan sağ çıxan tunelin heç biri yoxdur və planlaşdıra bilmədiyiniz növbəti hadisədə uğursuz olacaq.