IPv4 yönlendirmesinin VPN ağ geçidi yeniden başladıktan sonra da kalmasını sağlayın

Ağ geçidine ping atmak çalışıyor ama arkasındaki hiçbir şeye ulaşmak çalışmıyor ve bu bir tünel değil, yönlendirme sorununun şeklidir. Ağ geçidine yerel teslimat, tünelin açıldığını ve adres atamasının çalıştığını kanıtlar; çekirdeğin bir paketi bir arayüzden diğerine geçirip geçirmeyeceği hakkında hiçbir şey söylemez. Herhangi bir sysctl'e dokunmadan önce, makinenin bu trafiği yönlendirmek için tasarlandığını doğrulayın ve istemciye bakan arayüzü tutan ağ bağlamını bulun. Ardından değeri orada okuyun, okuduğunuz son kılavuzun tesadüfen baktığı yerde değil.

Ağ geçidine ulaşmak yönlendirme ile aynı şey değildir

Çekirdeğin içinde iki ayrı karar verilir. Yerel bir adrese teslimat paketin yolculuğunu bitirir; yönlendirme onu başka bir arayüzden yeniden dışarı gönderir ve bu ikinci karar her ağ ad alanı için yönetilir. Yönlendirme kapalıyken ağ geçidi tamamen erişilebilir olabilir ve bir ping isteminden iki arıza aynı görünür.

İstemci paketinin hangi arayüze geldiğini ve sonraki yolun hangi arayüzden çıktığını yazın. İkisi de tek bir ad alanına aittir ve önemli ayar o ad alanındadır.

Değeri paketlerin gerçekten bulunduğu yerde okuyun

Ana makine ad alanında yönlendiren bir ağ geçidinde tek bir komut soruyu yanıtlar: sysctl net.ipv4.ip_forward. Gelen ve sonraki yol adlandırılmış bir ad alanında yaşıyorsa o ad alanına sorun: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Ana makinenin değeri ad alanının değerinin yerine geçmez ve ana makinede bir olması hiçbir şeyin kanıtı değildir.

Her yönlendirme bağlamının ip netns komutuna verebileceğiniz bir etiketi yoktur. Konteyner çalışma zamanları ve hizmetler hiçbir zaman dostça bir adla kaydedilmeyen ad alanları oluşturur ve bunlar için çalışma zamanının inceleme araçlarını kullanırsınız. vpn-gw yerine gerçek adı veya aynı bağlama ulaşan çalışma zamanı mekanizmasını koyun ve ana makine düzeyinde tahmin etmeyi bırakın.

Ayara tek bir sahip verin

Geleneksel bir systemd ana makine ağ geçidinde kalıcı biçim, yöneticinin seçtiği bir adı taşıyan ve net.ipv4.ip_forward = 1 içeren /etc/sysctl.d/60-vpn-forwarding.conf gibi bir drop-in dosyasıdır. Dosyayı yazın, ardından canlı durumun da değişmesi için tam o dosyayı yükleyin: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, ardından bir geri okuma yapın. Dosya adı bir örnektir, ayrılmış bir VPN yolu değildir ve baştaki sayı önemlidir çünkü sonra sıralanan dosyalar kazanır.

Öncelik, kalıcılığın sessizce kırıldığı yerdir. Hem dağıtımın yükleyicisini hem de kendi drop-in dosyanızı kontrol edin, çünkü procps sysctl --system sonunda /etc/sysctl.conf dosyasını da okur, oysa systemd'nin sysctl.d sırası tamamen başka bir dizidir. Daha sonraki bir atama aynı anahtarı hemen geri koyabilir ve dosyanız doğru, etkin değer yanlış kalır. Bu tartışmayı kazanmak için var olan bir yönetici dosyasının üzerine yazmayın; sahibini bulun ve orada değiştirin.

Önyüklemeden sonra oluşturulan bir ad alanı ana makine drop-in dosyasıyla hiç yönetilmez. Ayarı onu oluşturan şeye aittir, ister konteyner çalışma zamanı ister ad alanının sağlama birimi olsun. Soruyu atlatmak için bir konteynere geniş ana makine ayrıcalıkları vermek, doğru sahibi belirlemek için on dakika harcamaktan daha kötü bir takastır.

Anahtarı çevirmeden önce neye mal olduğunu bilin

ip_forward zararsız bir boolean değildir. Çekirdek belgeleri, değiştirilmesinin birkaç başka IPv4 parametresini ana makine veya yönlendirici varsayılanlarına sıfırladığını belirtir, bu yüzden tanılama amaçlı bir çevirme başka bir yerde yapılan ince ayarı çöpe atabilir ve bundan hiç söz etmeyebilir. Onu gelişigüzel çalıştırılabilecek bir sonda değil, yan etkileri olan bir yapılandırma değişikliği olarak ele alın.

Bu, bir istemci bir ana makineye ulaşamadığında onu her seferinde kapatıp açmayı da dışlar. Değer zaten bir ise arıza yolun başka bir yerindedir ve aynı anahtarı üçüncü kez yeniden yazmak onu hareket ettirmez.

Kalıcılığı kanıtlayın, sonra yolun geri kalanını test edin

Değeri dört anda geri okuyun: değişiklikten hemen sonra, VPN arayüzü göründükten sonra, yeniden bağlandıktan sonra ve planlı bir yeniden başlatmadan sonra. Bu noktalardan herhangi birinde geri dönen bir değerin ikinci bir sahibi vardır ve bir kerelik bir yazma daha bunu yalnızca sonraki yeniden başlatmaya kadar saklar.

Etkinleştirilen yönlendirme hâlâ doğrulanacak üç şey bırakır. İstemcinin hedefe bir rotaya ihtiyacı vardır, ağ geçidinin bir sonraki rotaya ve onu kullanma iznine ihtiyacı vardır ve hedefin istemcinin tünel adresine bir dönüş yoluna ihtiyacı vardır. Özel yönlendirilmiş bir LAN otomatik olarak NAT'a ihtiyaç duymaz, bu yüzden üçünden hangisinin eksik olduğunu bilmeden masquerading eklemeyin ve ağ geçidinin kendisinden değil, amaçlanan istemciden test edin, çünkü ağ geçidinde başlayan bir istek yeni etkinleştirdiğiniz yönlendirme yoluna asla dokunmaz. IPv6 kendi yönlendirme ve yol politikasını taşır, bu yüzden çalışan bir IPv4 testi bunun hakkında hiçbir şey söylemez.

Runbook'ta drop-in yolunu, ad alanının sahibini ve geri okuma komutunu birlikte tutun. Bunu bir sonraki devralan kişi değeri okuyabilmeli, kimin sahip olduğunu görebilmeli ve sorunun kalıcılık mı yoksa yolun geri kalanı mı olduğuna bir dakika içinde karar verebilmelidir.