nftables cgroup atlatması da kaynak adres düzeltmesi gerektirir

Bir cgroup'u işaretlemek onu başka bir tabloya gönderir ve socket zaten sahip olduğu adresi korur. Sınıflandırma, yönlendirme ve çeviri üç ayrı adım olarak.

Bir cgroup'tan gelen trafiği işaretlemek işin kolay kısmı. Tek bir uygulama fiziksel arayüzden çıkarken geri kalan her şey tünelde kalacaksa üç ayrı kararın hizalanması gerekir: hangi socket istisnaya ait, işaret hangi yönlendirme aramasını tetikliyor ve paket çıkarken hangi kaynak adresi taşıyor. Başarısız denemelerin çoğu ilkini doğru yapar, ikincisini yarım yapar ve üçüncüsüne hiç bakmaz.

Üç karar, bir değil

Sınıflandırma kimin muaf olduğunu yanıtlar. Yönlendirme işaretli paketin onun yerine nereye gittiğini yanıtlar. Kaynak seçimi uzak ucun ne göreceğini ve yanıtın nereye dönmesi gerektiğini yanıtlar.

Bunlar birbirinden bağımsız olarak başarısız olur. Bir paket sınıflandırılabilir, fiziksel arayüze yeniden yönlendirilebilir ve yine de hiçbir üst akış yönlendiricisinin geri gönderemeyeceği özel bir adres taşıyabilir; bu da tam olarak güvenlik duvarı engellemesine benzeyen bir zaman aşımı üretir. Sınıflandırma adımında hiçbir şey sizi bu konuda uyarmaz. Yönlendirme adımında da hiçbir şey yok.

Sıra da önemlidir. Sınıflandırma paket oluşturulduğunda, yönlendirme ondan sonra, çeviri ise çıkış noktasında gerçekleşir.

Üç aşamadan hangisinin bozuk olduğunu adlandıramıyorsanız, hata ayıklamıyorsunuz, kuralları yeniden düzenliyor ve umuyorsunuz.

Yarın da var olacak bir cgroup ile eşleştirin

nftables bir socket'in cgroup v2 üyeliğini test edebilir; bu gerçekten yararlıdır çünkü hedefi değil süreci izler. Tuzak tanımlayıcıdadır. Menüden başlatılan bir masaüstü uygulaması genellikle bir sonraki başlatmada adı değişen geçici bir scope içinde yaşar.

nft list ruleset
systemctl status session.slice 2>/dev/null
cat /proc/self/cgroup

Bir oturumdan scope adını kopyalayıp sabit kodlamak, bugün çalışan ve yarın sessizce eşleşmeyi bırakan bir kural üretir. Bunun yerine uygulamayı denetlediğiniz özel bir scope veya unit gibi bilinçli, kararlı bir yürütme bağlamına koyun ve onunla eşleştirin. Kural böylece yeniden başlatmalara ve paket güncellemelerine dayanır. Ayrıca meslektaşınızın sizin oturum geçmişiniz olmadan üzerinde düşünebileceği bir şey hâline gelir.

Hangi mekanizmayı kullandığınız konusunda da kesin olun. cgroup v1'in net_cls sınıflandırması ile cgroup v2'nin socket eşleştirmesi farklı şeylerdir ve belgelerdeki benzer adlı bir alan onları birbirinin yerine kullanılabilir yapmaz.

İkinci aramayı tetikleyen şey route zinciridir

Yerel olarak oluşturulan trafik için zincir türü, işaret konulduktan sonra bir şey olup olmayacağına karar verir. filter türünde bir output zinciri paketi işaretleyebilir ve çekirdek zaten seçtiği rotayı kullanmaya devam eder. route türünde bir zincir, yeni bir arama isteyen mekanizmadır.

table inet bypass {
  chain mark {
    type route hook output priority mangle; policy accept;
    socket cgroupv2 level 2 "app.slice" meta mark set 0x1 comment "app bypass"
  }
}
ip rule add fwmark 0x1 lookup 200
ip route add default via 203.0.113.1 dev wlan0 table 200

Ardından işaretin onu bir tabloya gönderen bir politika kuralına ihtiyacı vardır ve o tablo eksiksiz olmalıdır: varsayılan rota, uygulamanın hâlâ gereksinim duyduğu yerel hedefler ve gerçekten yanıt veren bir üst akış ağ geçidi.

İşaret değerini bilinçli seçin. WireGuard dış taşıma trafiği için kendi fwmark'ını kullanır ve kazara aynı numaraya düşmek tünelin kendi rota istisnasını teşhisi zor biçimlerde bozabilir.

Kaynak adresi rotayı izlemez

Tünel yolu için zaten bir kaynak adres seçmiş olan socket, yeniden yönlendirmeden sonra da o adresi korur. Rota değişikliğinde hiçbir şey onu yeniden yazmaz, bu yüzden paket fiziksel arayüzden üst akış ağının geri gönderemeyeceği özel bir kaynakla çıkar.

Görünen belirti, veri gönderiyormuş gibi görünen ve hiç yanıt almayan bir uygulama ile paket hiç geri dönmediği için hiçbir şey göstermeyen bir güvenlik duvarı günlüğüdür.

Dar düzeltme, o uygulamanın işaretine ve gerçek çıkış arayüzüne sınırlanmış, zaten var olan NAT ile bütünleşen, onu değiştirmeyen bir kaynak çeviri kuralıdır:

table inet bypass {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    meta mark 0x1 oifname "wlan0" masquerade
  }
}

Yalnızca istisnayı çevirin, başka hiçbir şeyi değil. Genel bir masquerade kuralı belirtiyi düzeltir ve hangi trafiğin hangi yolu izlediğini söyleme yeteneğinizi yok eder. İşareti, gerçek çıkış arayüzünü ve mümkünse uygulamanın kendi adresini eşleştirin. Geniş kurallar yazması kolay, sonradan denetlemesi neredeyse imkânsızdır.

İstisnadan hâlâ ne kaçıyor

Ad çözümlemesi başka bir cgroup'taki ayrı bir resolver sürecinden gelebilir, bu yüzden tarayıcının socket'ini sınıflandırmak onun aramalarını sınıflandırmaz. Resolver'ın sorguları tünelde kalırken bağlantı dışına çıkarsa split-horizon yanıtları yolla eşleşmeyebilir. Bu uyumsuzluk DNS hatası gibi görünen ama olmayan arızalar üretir.

Alt süreçler çoğu kurulumda cgroup'u devralır, ancak kendini kendi scope'una taşıyan bir yardımcı devralmaz. Varsaymak yerine denetleyin, özellikle kendini yeniden çalıştıran her şey için.

Son olarak tünel kapalıyken ne olması gerektiğine karar verin. Sessizce tam bir atlatmaya dönüşen bir istisna, başarısız olduğunda kapanan bir istisnadan farklı bir güvenlik duruşudur ve yalnızca biri sizin kastettiğinizdir.

İlgili makaleler