Linux VPN yanıtları kayboluyor mu? rp_filter ve rotayı kontrol edin

İstekler makineden çıkıyor, VPN eşi yanıtlıyor ve yanıt hiçbir zaman sokete ulaşmıyor. Tünel ayakta, eşin günlükleri paketin gönderildiğini gösteriyor ve uygulamada bu sessizliği açıklayan hiçbir şey yok. Linux'ta olağan şüphelilerden biri ters yol filtrelemedir: gelen IPv4 paketi, kaynak doğrulaması çekirdeğin o kaynak için beklediği rota ile uyuşmadığında reddedilebilir. Sırayla ilerlemek bunun neden mi yoksa tesadüf mü olduğunu söyler. Ayrıca eksik bir rotayı düzeltmek için bir güvenlik denetimini kapatmanızı da önler.

Kaynak doğrulaması neye karar veriyor

Çekirdek, bir paketin kaynak adresinin geldiği arayüz için akla yatkın olup olmadığını, yönlendirme tablosuna o kaynağa geri giden bir rota için bakarak denetler. Ters rota başka bir yeri gösteriyorsa paket, herhangi bir güvenlik duvarı kuralı veya uygulama soketi onu görmeden önce düşürülebilir. Bu denetim bazı sahtekârlık kalıplarını zorlaştırmak için vardır ve bu yüzden asimetrik ve ilke tabanlı yönlendirilen tasarımlar ona takılırken aynı ağdaki her sıradan istemci sorunsuz çalışır. Sıradan istemciler simetrik yönlendirmeye sahiptir ve denetimin varsaydığı tam olarak budur.

Önemli kelime akla yatkın. Paket tamamen meşru olabilir ve yine de denetimden geçemeyebilir, çünkü sınanan meşruiyet değildir.

Etkin modu okuyun, tek bir alanı değil

Üç mod vardır: devre dışı, katı ve gevşek. Katı, gevşekten farklı bir rota beklentisi dayatır ve genel ayar her arayüz için olanlarla etkileşir, bu yüzden tek bir dosyayı okumak gerçekte yürürlükte olanı yanlış tanımlayabilir. İkisini de okuyun ve yanıtı alan arayüzde okuyun, varsayılan rotanın arayüzünde değil.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

Üçüncü satırdaki rota araması insanların atladığı kısımdır. Çekirdeğin kaynak hakkında ne düşündüğünü söyler ve bu tam olarak denetimin girdisidir.

Denetimi değiştirmeden önce uyuşmazlığı bulun

Yanıtın neden o arayüze geldiğini ve ters rotasının farklı olup olmaması gerektiğini belirleyin. İstekleri bir yoldan gönderip yanıtları başka bir yoldan döndüren bir ilke kuralı meşru bir tasarımdır ve katı doğrulamanın reddettiği tasarım da tam olarak budur. İlke yönlendirmede kullanılan işaretler burada da önemli olabilir, çünkü ters aramanın ne döndürdüğünü değiştirirler.

Ters rota yalnızca eksikse, onu eklemek bir denetimi kapatmak yerine nedeni düzeltir. Eksik rota, güvenlik duvarı reddi ve yanlış trafik seçici aynı görünür belirtiyi üretir ve bunlardan yalnızca biri kaynak doğrulamasıyla ilgilidir.

Kaynak denetimlerini ilk tepki olarak genel olarak kapatmayın. Bu, belirli bir tanıyı daha sonra hatırlamanız gereken geniş bir davranış değişikliğiyle değiştirir.

Savunabileceğiniz seçici bir ayarlama

Gerçekten dar bir ayarlama gerekiyorsa, onu ihtiyaç duyan arayüzle sınırlayın, nedenini yazın ve yeniden başlatmadan sonra da kalması için o arayüzün sahibi olan yapılandırmaya koyun. Sonra başarısız olan tam akışı aynı kaynaktan aynı hedefe yeniden test edin, uygun bir şeye ping atmak yerine.

Hâlâ reddedilmesi gereken bir durumu dahil edin. O durum artık başarılı oluyorsa, ayarlama onarmak istediğiniz tek yoldan fazlasını zayıflatmıştır.

IPv4 ve IPv6'yı ayrı tutun

Tanıdık görünen bir sysctl her adres ailesi için bir ilke değildir. IPv6'nın kendi davranışı ve kendi ayarları vardır ve bir makine bir ailede katı, diğerinde hoşgörülü olabilir; belirli bir hedef başarısız olana kadar kimse fark etmez. İş yükü ikisini de kullanıyorsa ikisini de denetleyin.

Modu, arayüzü, rota aramasının çıktısını ve değişikliğin nedenini tek bir yerde kaydedin. Sonraki kişi ayarı bulacak ve hiçbir açıklama bulamayacak, ardından onu ya kaldıracak ya da ait olmadığı bir yere kopyalayacak.