iptables kuralınız köprülenmiş VPN trafiğini neden hiç görmez

Aynı ana makinedeki iki sanal makine bir köprü üzerinden LAN'a ulaşır ve ip forward zincirine konan kural hiç hareket etmeyen bir sayaç gösterir. Çerçeveler gerçektir, trafik geçmektedir ve kural yalnızca onun yolunda değildir. Linux'un köprü trafiğini iki farklı biçimde görünür kılmasını karşılaştırmak bu sessizliği açıklar ve bir eski modülü yüklemenin neden göründüğünden daha kötü bir yanıt olduğunu da açıklar.

Tek bir ana makineden iki yol

Bir paket bu ana makineden iki çok farklı biçimde çıkabilir ve fark, hangi kancaların onu göreceğini belirler. Hedef fiziksel bir bağlantı noktasının ötesindeyse ve çerçeve köprünün iki bağlantı noktası arasında anahtarlanıyorsa, ana makine bir Ethernet çerçevesi iletir; yönlendirme koduna sorulmaz ve yönlendirilmiş bir sıçrama olmaz. Hedef ana makinenin kendisiyse veya bir tünel arayüzü üzerinden ulaşılan bir ağsa, paket yönlendirilir ve IP katmanının kancaları gerçekten geçerli olur. Bu çatalı aklınızda tutun, çünkü zincirler ve aileler hakkındaki her sonraki soru, bir çerçevenin iki yoldan hangisini seçtiğinden doğar.

Bu ayrım, hiçbir şey saymayan bir kuralın arkasındaki tüm hikâyedir. veth9a1 konumundan enp3s0 konumuna köprülenmiş bir çerçeve IP yığınını değil köprüyü geçer, bu yüzden ip forward zinciri eşleştirecek bir şey görmez. Daha eski bir örnekteki arayüz adları hangi yolda olduğunuzu belirlemez ve bu yüzden ilk adım kural kümesine değil topolojiye bakmaktır.

Tünel, adlandırılmaya değer üçüncü bir durum ekler. Bir TUN aygıtı IP paketlerini ana makineye teslim eder, dolayısıyla bunlar yönlendirilir ve gerçekten IP zincirlerinden geçer; köprüye bağlı bir TAP aygıtı ise çerçeve teslim eder ve köprü durumu gibi davranır. Aygıt türü belirler, ürün adı değil.

Köprülenmiş bir çerçeveyi görebilen iki aileyi karşılaştırın

Linux, nftables'ın bridge ailesi üzerinden yerel köprü filtrelemeyi destekler ve uçuştaki çerçeveleri inceleyip düşürmek için hiçbir eski modüle ihtiyaç duymaz. Çekirdeğin kendi köprü belgeleri bu öneriyi doğrudan verir; bir arama sonucu size modül yüklemenizi söylemeden önce bunu bilmek faydalıdır.

iptables yerine nft komutunu kullanmak, kuralı tek başına doğru aileye yerleştirmez. bridge ailesinde bildirilen bir zincir çerçeveleri görür; ip, ip6 veya inet içinde bildirilen bir zincir, hangi ikili dosya oluşturursa oluştursun onları görmez. Aile zincirin özelliğidir, onu yazan aracın değil.

Eski yol farklı çalışır ve bu yüzden alışkanlıkla taraf seçmek yerine karşılaştırmak gerekir. br_netfilter modülünü yüklemek ve bridge-nf-call ayarlarını etkinleştirmek, köprülenmiş IPv4 ve IPv6 trafiğini yeniden IP katmanının kancaları üzerinden görünür kılar, böylece sıradan bir iptables kuralı sonunda onunla eşleşebilir. Çerçeveler değişmez; geçtikleri kanca kümesi değişir, bu da her mevcut ana makine kuralının artık yeni bir izleyici kitlesi olduğu anlamına gelir.

Kural eklemeden önce gerçek yolu okuyun

Üç komut nerede olduğunuzu belirler: köprünün neye bağlı olduğunu, eski modülün etkin olup olmadığını ve bridge ailesinde hangi zincirlerin zaten bulunduğunu. Bir şey yazmadan önce bunları çalıştırın, çünkü yanıt iki tasarımdan hangisini genişlettiğinizi belirler. Bu adımı atlamak, doğru bir kuralın hiçbir şeyin geçmediği bir zincire düşmesinin yoludur.

bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"

Çıktı durumları temiz biçimde ayırır. Köprünün altında listelenen bağlantı noktaları hangi arayüzlerin anahtarlandığını söyler; boş bir lsmod sonucu, köprülenmiş çerçevelerin IP katmanında hiçbir görünürlük olmadığı anlamına gelir; bridge ailesinin var olan forward zinciri, politika sahibinin zaten bulunduğu ve kuralınızın kendi yeni zincirine değil oraya ait olduğu anlamına gelir.

Ardından geri okunması kolay bir kural ekleyin, sayaçla ve hükmü değiştirmeden, ve bir temsili akışı köprüden geçirin. Hareket eden sayaç, çerçevenin kurala ulaştığını kanıtlar. Kanıtladığı tek şey budur, bu yüzden reddedilen yolu da izleyin, çünkü her şeyi kabul eden bir politika da hareket eden sayaç üretir.

nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter accept

Eski modülün davranışı değiştirdiği yer

Çalışan bir köprüde eski yolu etkinleştirmek, görünürlük eklemenin tarafsız bir eylemi değildir. Daha önce köprü trafiği için erişilemez olan kurallar erişilebilir hale gelir, başka bir arayüz için yazılmış ana makine kuralları dahil, ve ip forward zincirindeki varsayılan drop politikası bir anda eskiden dokunulmadan geçen çerçevelere uygulanabilir. O köprü üzerinden yönetilen bir ana makinede sonuç, konsolu olmayan bir kilitlenmedir. Bu varsayımsal bir hata modu değildir; yeni genişlettiğiniz yoldan ulaştığınız bir makinede kanca kümesini genişletmenin olağan sonucudur.

Daha güvenli sıra, hangi ailenin politikaya sahip olduğuna karar vermek, kuralları oraya yazmak ve herhangi bir sysctl değiştirmeden önce bağımsız bir kurtarma yolu tutmaktır. İki aile de kural tutuyorsa hangisinin yetkili olduğunu belgeleyin; üst üste binen iki politika, bir paketin bir yerde kabul edilip başka bir yerde düşürülmesinin, okunacak tek bir dosya olmadan gerçekleşme biçimidir.

Yalıtımın kendisi hâlâ eksiksiz bir tasarım gerektirir. Bir kaynağın bir hedefe izin verilmesi yalnızca bir akışın çalıştığını kanıtlar, oysa gereksinim genellikle bir VM'in komşularına veya ana makineye ulaşamamasıdır. Reddetme kurallarındaki sayaçlar, kabul kuralındaki sayaçtan daha önemlidir, çünkü kabul sayacı hareket etmesini zaten beklediğiniz olandır.

Son olarak, ana makine girişi durumunu ayrı tutun. Köprünün kendi IP adresine yönlendirilen trafik forward'a değil input'a gelir ve forward'daki bir kural hangi aileyi seçerseniz seçin onu asla görmez. Üç durum, iki aile, tek ders: yolu kanca belirler ve kanca kuralınızın var olup olmadığını belirler.