IPv4 yönləndirməsini VPN şlüzünün yenidən başlamasından sonra da qalıcı et

Şlüzü ping etmək işləyir, arxasındakı heç bir şeyə çatmaq isə işləmir; bu, tunel problemi deyil, yönləndirmə probleminin formasıdır. Şlüzə yerli çatdırılma tunelin qalxdığını və ünvan təyininin işlədiyini sübut edir; lakin nüvənin paketi bir interfeysdən digərinə ötürüb-ötürməyəcəyi barədə heç nə demir. Hər hansı sysctl-ə toxunmazdan əvvəl maşının bu trafiki marşrutlaşdırmaq üçün nəzərdə tutulduğunu təsdiqlə və müştəriyə baxan interfeysi saxlayan şəbəkə kontekstini tap. Sonra dəyəri orada oxu, oxuduğun son bələdçinin təsadüfən baxdığı yerdə deyil.

Şlüzə çatmaq yönləndirmə ilə eyni şey deyil

Nüvənin içində iki ayrı qərar verilir. Yerli ünvana çatdırılma paketin səyahətini bitirir; yönləndirmə onu başqa interfeysdən yenidən çölə göndərir və bu ikinci qərar hər şəbəkə ad fəzası üzrə idarə olunur. Şlüz tamamilə əlçatan ola bilər, yönləndirmə isə söndürülmüş ola bilər və ping əmrindən bu iki nasazlıq eyni görünür.

Müştəri paketinin hansı interfeysdən gəldiyini və sonrakı yolun hansı interfeysdən çıxdığını yaz. İkisi də bir ad fəzasına aiddir və həmin ad fəzası vacib olan parametri saxlayır.

Dəyəri paketlərin həqiqətən olduğu yerdə oxu

Host ad fəzasında marşrutlaşdıran şlüzdə bir əmr suala cavab verir: sysctl net.ipv4.ip_forward. Giriş və sonrakı yol adlı ad fəzasında yerləşirsə, o ad fəzasından soruş: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Host dəyəri ad fəzası dəyərinin əvəzedicisi deyil və hostda birlik heç bir şeyin sübutu deyil.

Hər marşrutlaşdırma kontekstinin ip netns-ə verə biləcəyin bir etiketi yoxdur. Konteyner mühitləri və xidmətlər heç vaxt dost adla qeydiyyata alınmayan ad fəzaları yaradır və onlar üçün mühitin yoxlama alətlərindən istifadə edirsən. vpn-gw yerinə həqiqi adı və ya eyni kontekstə çatan mühit mexanizmini qoy və host səviyyəsində təxmin etməyi burax.

Parametrə tək sahib ver

Adi systemd host şlüzündə davamlı forma, administratorun seçdiyi adla /etc/sysctl.d/60-vpn-forwarding.conf kimi bir drop-in faylıdır və içində net.ipv4.ip_forward = 1 olur. Faylı yaz, sonra canlı vəziyyətin də dəyişməsi üçün məhz həmin faylı yüklə: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, ardınca geri oxuma. Fayl adı nümunədir, qorunan VPN yolu deyil və başdakı rəqəm önəmlidir, çünki sonra sıralanan fayllar qalib gəlir.

Üstünlük davamlılığın səssizcə qırıldığı yerdir. Paylanma yükləyicisini də, öz drop-in faylını da yoxla, çünki procps sysctl --system sonda /etc/sysctl.conf faylını da oxuyur, systemd-in sysctl.d sırası isə tamamilə fərqli ardıcıllıqdır. Sonrakı təyinat eyni açarı dərhal geri qoya bilər və faylın düzgün, effektiv dəyər isə səhv qalar. Bu mübahisəni udmaq üçün mövcud administrator faylını üzərinə yazma; sahibi tap və orada dəyiş.

Yükləmədən sonra yaradılan ad fəzası host drop-in faylı ilə heç idarə olunmur. Onun parametri onu yaradan şeyə aiddir, istər konteyner mühiti, istərsə də ad fəzasının təchizat vahidi olsun. Sualdan yayınmaq üçün konteynerə geniş host imtiyazları vermək düzgün sahibi tapmaq üçün on dəqiqə sərf etməkdən daha pis bir mübadilədir.

Açarı çevirməzdən əvvəl onun nəyə başa gəldiyini bil

ip_forward zərərsiz boolean deyil. Nüvə sənədləri qeyd edir ki, onun dəyişdirilməsi bir neçə başqa IPv4 parametrini host və ya marşrutlaşdırıcı defoltlarına qaytarır, buna görə diaqnostik çevirmə başqa yerdə edilən tənzimləməni atıb onu heç xatırlaya bilməz. Ona təsadüfən işlədilə bilən yoxlama kimi deyil, yan təsirləri olan konfiqurasiya dəyişikliyi kimi yanaş.

Bu həm də müştəri hosta çata bilməyəndə onu hər dəfə söndürüb yandırmağı istisna edir. Dəyər artıq birdirsə, nasazlıq yolun başqa yerindədir və eyni açarı üçüncü dəfə yenidən yazmaq onu tərpətməyəcək.

Davamlılığı sübut et, sonra yolun qalan hissəsini sına

Dəyəri dörd anda geri oxu: dəyişiklikdən dərhal sonra, VPN interfeysi göründükdən sonra, yenidən qoşulmadan sonra və planlı yenidən başlatmadan sonra. Bu nöqtələrin hər hansı birində geri qayıdan dəyərin ikinci sahibi var və bir daha tək seanslıq yazı onu yalnız növbəti yenidən başlatmaya qədər gizlədir.

Yönləndirmə aktiv olsa da yoxlanmalı üç şey qalır. Müştəriyə təyinat yerinə marşrut, şlüzə sonrakı marşrut və ondan istifadə icazəsi, təyinat yerinə isə müştəri tunel ünvanına qayıdış yolu lazımdır. Şəxsi marşrutlaşdırılmış LAN avtomatik olaraq NAT tələb etmir, ona görə üçündən hansının çatışmadığını bilməzdən əvvəl masquerading əlavə etmə və şlüzün özündən deyil, nəzərdə tutulan müştəridən sına, çünki şlüzdə yaranan sorğu yenicə aktiv etdiyin yönləndirmə yoluna heç vaxt toxunmur. IPv6 öz yönləndirmə və marşrutlaşdırma siyasətini daşıyır, buna görə işləyən IPv4 sınağı onun barədə heç nə demir.

Drop-in yolunu, ad fəzası sahibini və geri oxuma əmrini runbook-da birlikdə saxla. Bundan sonra bunu götürən şəxs dəyəri oxuya, kimin sahib olduğunu görə və bir dəqiqə içində problemin davamlılıq, yoxsa yolun qalan hissəsi olduğuna qərar verə bilməlidir.