Niyə net.ipv4.conf.default.forwarding tun0-a toxunmur

Siz net.ipv4.conf.default.forwarding=1 təyin etdiniz, VPN-i yenidən başlatdınız, amma tunel hələ də gateway-in yönləndirməli olduğu paketləri atır. Ayar faylda doğru görünür, interfeys isə hələ də forwardinqin söndürüldüyünü bildirir. Heç nə pozulmayıb: siz gələcək interfeyslərin miras aldığı dəyəri dəyişdiniz, canlı tunelin istifadə etdiyi dəyəri yox.

Bunu tunelə sahib olan hostda, tunelin həqiqətən mövcud olduğu şəbəkə namespace-ində addım-addım yoxlayın. Konteyner və ya şəbəkə namespace-i interfeysi saxlaya bilər, host isə fərqli rəqəmlər göstərə bilər.

Üç dəyəri birlikdə oxuyun

Gateway üzrə açarı, yeni interfeyslər üçün şablonu və sizi maraqlandıran interfeysi müqayisə etməklə başlayın. Sonra tun0 əvəzinə real giriş interfeysini yazın və qayıdış interfeysini də oxuyun, çünki forwardinq paketin gəldiyi nöqtədə qiymətləndirilir.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Adi nəticə belədir: ip_forward = 0, default.forwarding = 1 və tun0.forwarding = 0. İlk ikisi hostun rolu barədə razılaşmır, üçüncüsü isə interfeysin əslində nə etdiyini göstərir. Bu kombinasiya heç vaxt router kimi konfiqurasiya edilməmiş, yalnız şablon dəyəri verilmiş hosta uyğundur. Üç rəqəm bir-birinə zidd deyil; onlar üç fərqli suala cavab verir. Şablon dəyərini yazmaq da hostun rolunu həll etmir.

Niyə hərəkət edən məhz qlobal açar

net.ipv4.ip_forward gateway üzrə idarəetmədir. Onu dəyişmək həmin əməliyyatın bir hissəsi olaraq hər interfeys üzrə forwardinq ayarlarını yeniləyir, buna görə də bir yazma mövcud tunelin forwardinqə başlamasına səbəb ola bilər. default.forwarding yalnız sonradan işə salınan interfeysləri qidalandırır, ona görə artıq mövcud olan tunel doğulduğu dəyəri saxlayır.

Kernel sənədləri ip_forward işarəsini əlaqəli səbəbə görə xüsusi qeyd edir: onu dəyişmək bir sıra digər IPv4 parametrlərini host və ya router defoltlarına qaytarır. Bu onu küt alətə çevirir. Gateway rolunun qurulması çərçivəsində onu bir dəfə təyin etmək yaxşıdır; amma sazlama hiyləsi kimi dəfələrlə dəyişmək, düzəltməyə vaxt sərf etdiyiniz konfiqurasiyanı səssizcə yenidən yaza bilər.

Hər interfeys üzrə dəyərlər də bir səbəbə görə mövcuddur. Qəsdən idarə olunan gateway heç vaxt yönləndirməməli olan interfeysdə forwardinqi söndürülmüş saxlaya bilər, hətta host başqa yerdə yönləndirsə də. Buna görə canlı interfeysi oxumaq vacibdir və buna görə tək qlobal dəyər tam cavab deyil. Belə istisnanı qəsdən verilmiş qərar kimi oxuyun və həmin interfeysin niyə fərqli olduğunu yazın. Əks halda növbəti mühəndis onu xeyirxahlıqla "düzəldəcək".

Ayarı düzgün yerdə davamlı edin

Uğurlu birdəfəlik sysctl -w kernelin dəyəri qəbul etdiyini sübut edir. Lakin yenidən başlatmadan sonra qalmır və yenidən qoşulma zamanı interfeys konfiqurasiyası barədə öz fikrini tətbiq edən şəbəkə menecerindən sonra da qalmır. Gateway rolunu sysctl konfiqurasiya faylına və ya hosta sahib olan şəbəkə menecerinə yazın, sonra onu tətbiq edən xidməti yenidən başladın.

Tunellərdə sıra vacibdir. Əgər menecer interfeysi açılışda yaradır və forwardinqi sonra tətbiq edirsə, interfeys köhnə defoltu miras ala bilər. Tuneli yenidən yaradan xidmət yenidən başlatması da yaradılma hadisəsidir və unit sağlam görünəndə bunu qaçırmaq asandır. Yalnız yekun fayl məzmununa deyil, ardıcıllığa baxın.

VPN yenidən qoşulduqdan sonra və yenidən başlatmadan sonra eyni üç dəyəri yenidən oxuyun. Yeni yaradılmış tunel yeni interfeysdir və yeni interfeys yaradılma anında qüvvədə olan defoltu götürür. Əgər rəqəmlər bu hadisələr boyu dəyişirsə, konfiqurasiya hələ müəyyən etmədiyiniz bir şey tərəfindən tətbiq olunur.

Bunu yanlış alətlə düzəltməyin

Forwardinq pozulmuş görünəndə firewall-u təmizləmək və ya masquerading əlavə etmək istəyi yaranır. Heç biri forwardinq açarını həll etmir. Forwardinq vəziyyəti, yönləndirmə icazəsi, təyinat üçün marşrut və qayıdış yolu dörd ayrı tələbdir və yalnız birincisi sysctl-dir.

Həm də düzgün axınla sınaqdan keçirin. Gateway-in özündə edilən sorğu forwardinqi heç işə salmır; bu, lokal yaradılan trafikdir. Sual budur: VPN müştərisindən və ya LAN hostundan gələn paket qəbul olunub irəli yönləndirilirmi, ona görə test gateway-in arxasından başlamalıdır.

IPv6 halını ayrı saxlayın

Burada hər şey IPv4-dür. IPv6 forwardinqi, router reklamları və accept_ra davranışının öz idarəetmələri var və ipv4 yolunu ipv6 ayarına köçürmək inandırıcı görünən, amma faydalı heç nə etməyən fayl yaradır. İkiqat stack gateway hər iki dəsti qəsdən konfiqurasiya etməlidir.

Son bir yoxlama: dəyərlər uyğunlaşdıqdan sonra tunelin marşrutunun təyinat üçün seçildiyini və cavab yolunun mövcud olduğunu təsdiqləyin. Marşrutsuz interfeysdə aktiv forwardinq yenə qara dəlikdir və bu nasazlıq müştəri tərəfindən eyni görünür.