Ofis yerel ağındaki bir VPN istemcisi her yanıtı neden kaybediyor

Bir dizüstü bilgisayar Ethernet üzerinden ofisin /24 ağında oturuyor ve aynı /24 içinde yaşayan bir OpenVPN sunucusuna da katılıyor. Bir iş arkadaşı tünel adresine ping atıyor; istek açıkça ulaşıyor ve geri hiçbir şey gitmiyor. Tünel günlüğü temiz ve tarayıcı hâlâ çalışıyor, yani tünel yanlış şüpheli. Alan makinede IPv4 kaynak doğrulaması paketi herhangi bir şey okumadan önce atıyor.

Atma, herhangi bir şey paketi okumadan önce gerçekleşir

Kaynak doğrulaması her gelen paket hakkında tek bir soru sorar: bu ana makine o kaynağa yanıt verseydi, yanıt paketin az önce geldiği arabirimden mi çıkardı? Yanıt hayırsa çekirdek paketi geldiği anda atar. Ne bir soket ne bir iletme yolu onu hiç görmez, bu yüzden tüneldeki bir yakalama uygulamanın asla almadığı bir isteği hâlâ kaydeder.

Buradaki istemci tünelinde 10.66.0.9 tutuyor ve OpenVPN sunucusu ofis öneki içinde 192.168.80.10 adresinden yanıt veriyor. 192.168.80.25 adresindeki iş arkadaşı tünel adresine ping atıyor, böylece istek yerel ağı geçiyor, sunucu onu tünele yönlendiriyor ve ofisin kaynak adresini taşıyarak istemcinin tünel arabirimine varıyor. O makinenin yönlendirme tablosunda ofis öneki Ethernet aygıtına ait, tünele değil. Doğrulama varış arabirimini yolla karşılaştırır, uyuşmazlık bulur ve paketi atar, böylece iki uç da sağlıklı bir tünel bildirirken iş arkadaşı tam kayıp görür.

Ayna yönü aynı biçime sahiptir: istemci ofise doğru başladığında yanıtlar ofis tarafında tam olarak aynı nedenle atılabilir. Yalnızca tek yönde doğrulanan bir düzeltme genellikle ikinci bir bilet olarak geri döner.

Herhangi bir sysctl'e dokunmadan önce yürürlükteki kipi kanıtlayın

Bir dağıtım varsayılanına güvenmek yerine gerçek değerleri okuyun, çünkü arabirim başına ayar kararın yalnızca yarısıdır. Yürürlükteki kip arabirim değeri ile all değerinin yükseğidir, bu yüzden tünel arabirimindeki sıfır all bir olduğu sürece hiçbir şey ifade etmez. Katı kipin kararı bir yönlendirme kararıdır, bu yüzden çekirdeğin yaptığı aramayı çalıştırın ve yanıtını paketin gerçekten geldiği arabirimle karşılaştırın.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Sonra hata sayacını izleyerek pingi yineleyin. Yakalamanın zaten gösterdiği bir isteğin yanında artan sayı bu atmanın imzasıdır, eksik bir yolun değil. Oradayken Mars paketi günlüklemesini açın, böylece çekirdek reddettiği kaynağı ve arabirimi adlandırsın. Birlikte şifrelemeyi, güvenlik duvarını ve eksik iroute tanımını açıklama olarak dışlar.

Bir şeyi değiştirmeden önce başlangıç durumunu yazın: her iki değer, aramanın seçtiği aygıt ve izlediğiniz sayaç. Değişikliğin düşündüğünüzü yapıp yapmadığını size sonra söyleyen o kayıttır.

Her rp_filter kipi gerçekte neyi kabul eder

Çekirdek arabirim başına üç değer sunar ve bunlar tek bir kuralın üç tonu değildir. Sıfır denetimi kapatır. Bir katıdır ve kaynağın varış arabiriminden geri yönlendirilmesini ister. İki gevşektir ve tabloda kaynağa giden herhangi bir yolun bulunmasını yeterli görür, nereye işaret ederse etsin.

Burada önemli olan satır gevşek olandır ve reddetmeye devam ettiği şeydir. Tablonuzda herhangi bir yerde yönlendirilebilen sahte bir kaynak geçer, hiç yolu olmayan bir kaynak ise hâlâ reddedilir. Dizüstünde bu dar bir tavizdir; başkalarının trafiğini ileten bir yönlendiricide geniştir. Kip ana makineye aittir, bu yüzden aynı sayı iki yerde farklı ağırlık taşır.

Bu topolojinin hangi satıra ihtiyaç duyduğu alışkanlıktan değil tablodan çıkar. Paket meşrudur ve kaynağı yönlendirilebilir, bu yüzden gevşek olan kabul eder, katı olan etmez. Bu davada hiçbir şey sıfır istemez ve sıfırı seçmek burada hiçbir maliyeti olmayan bir denetimi kaldırırdı.

Belirsizliği ortadan kaldıran en küçük değişikliği seçin

Gevşek kip uyan en küçük değişikliktir ve zararsız bir anahtar değil, katılıkta gerçek bir azalmadır. Topoloji izin verdiğinde daha iyi bir seçenek vardır: örtüşmeyi kaldırın ve belirsizlik kaybolur.

Ofis öneki yalnızca Ethernet üzerinden gerekiyorsa, onu profilin çektiği yollardan çıkarın ve adres tek bir yoldan erişilebilir olur. İki yol gerçekten birlikte var olmak zorundaysa, her arabirimde doğrulamayı gevşetmek yerine bir ilke kuralıyla kaynağı ve aygıtı sabitleyin. Bu, makinedeki diğer her şey için katı filtrelemeyi korur ve istisnayı bir sonraki mühendisin arayacağı yerde belgeler.

Hangi yolu seçerseniz seçin, onu canlı bir komutta değil bir sysctl drop-in dosyasında kaydedin. all ve default anahtarlarını birlikte ayarlayın, böylece yeniden bağlanma katı kipi sessizce geri getiremez.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Gevşek kip nelerden vazgeçer ve nerede

Gevşek kip hiçbir yolun ulaşamayacağı bir kaynağı hâlâ reddeder ve tesadüfen yönlendirilebilir olan sahte kaynağı reddetmeyi bırakır. Dizüstünde bu dar bir tavizdir. Kendisine ait olmayan trafiği ileten bir aygıtta aynı seçim çok daha geniştir. Bu yüzden aynı ayar nerede çalıştığına bağlı olarak iki çok farklı anlam taşır.

Başkaları için trafik ileten bir ana makinede denetimi tamamen kapatmak kaçınılması gereken tek onarımdır. Sıfır, gevşek kipin özenle koruduğu doğrulamayı atar. Ana makine başkaları için iletiyorsa, bunun yerine önceki bölümdeki ilke kuralı seçeneğini savunun.

İki arabirimi, örtüşen öneki ve artık başarılı olan tam testi adlandıran bir not bırakın. Bu, bir sonraki mühendis için filtrelemenin ayarlandığını söyleyen bir satırdan daha yararlıdır.