Her VPN istemci havuzu için tek bir hedef aralığını engelleyin
Tek bir nftables kuralı, ağ geçidinin kendi trafiğine dokunmadan izin verilen bir VPN havuzu için hedef önekini reddedebilir. Kancayı ve konumu doğru eşleştirin.
Tek bir kural, izin verilen bir VPN havuzunu hedef aralığından uzak tutabilir ve ağ geçidinin yaptığı başka hiçbir şeyi bozmaz. Kuralın kendisi kısadır; işe yarayıp yaramayacağını belirleyen parçalar, içinde yaşadığı kanca ve zincirdeki konumudur. Bu ikisini yanlış yaparsanız doğru görünen ama tutarsız davranan bir güvenlik duvarı elde edersiniz. Kural paketi gördüğünde paketin ne yaptığından başlayın.
Kural gerçekte neyi eşleştirir
Kural aynı anda üç şeyi eşleştirir: bir giriş arayüzü, bir kaynak öneki ve bir hedef öneki. Drop uygulanmadan önce üçü de doğru olmalıdır ve bu onu dar tutar. Onu tek bir ifade olarak okumak, üç ayrı politika olarak okumaktan daha kolaydır.
Arayüz eşleşmesi, iletilen istemci trafiğini ağ geçidinin kendi bağlantılarından ayıran şeydir. O olmadan, yalnızca kaynak havuzunu adlandıran bir kural, ağ geçidinin kendisinin o adresten ürettiği paketleri de etkilerdi, eğer bu hiç olursa. Kaynak öneki politikayı izin verilen istemcilerle, hedef öneki ise tek bir aralıkla sınırlar. Kuralı liste olarak değil, kesişim olarak okuyun.
Herhangi bir şeyi düzenlemeden önce üç değeri yazın: tünel arayüzünün adı, sunucunun dağıttığı havuz ve reddetmeyi düşündüğünüz önek. Bunlardan herhangi birindeki bir yazım hatası, temiz ayrıştırılan ama hiçbir şeyi korumayan bir kural üretir. Bu üç değeri kuralın yanındaki değişiklik kaydında tutun.
Kanca kuralın kimi kapsadığına karar verir
Bir netfilter zinciri bir kancaya bağlıdır ve hangi paketleri zincirin gördüğünü kanca belirler. forward kancası ağ geçidinden yönlendirilen trafiği görür ve bu tam olarak istemciden hedefe giden trafiktir. Zincirdeki diğer her şey başka bir kitleye yöneliktir.
input kancası doğrudan ağ geçidine adreslenen trafiği görür, bu yüzden oraya konan bir kural geçişi değil kendi hizmetlerine erişimi yönetir. output kancası ağ geçidinin kendi ürettiği trafiği görür ve bu, istemci havuzu politikasının ihtiyaç duyduğunun tam tersidir. Zincir adları, kural kümesini yazan kişinin seçtiği gelişigüzel etiketlerdir, bu yüzden kancayı addan çıkarsamayın. Kancanın neyi eşleştirebileceğini varsaymadan önce zincirin nereye bağlı olduğunu kontrol edin.
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
Bağlantıyı okumak, bir kuralın paketi hiç görmeyen bir zincire düşmesini önleyen tek satırlık bir kontroldür.
Kuralı geniş accept'ten önce yerleştirin
Kurallar sırayla değerlendirilir ve ilk hüküm kazanır. Zincirde daha önce yer alan geniş bir accept, eşleştiği paketler için değerlendirmeyi bitirir, bu nedenle sonradan eklenen bir drop onlar için hiç çalışmaz. Bu sıra kuralı, doğru görünen bir kuralın neden hiçbir etkisi olmayabileceğinin tüm nedenidir.
Kuralı sona eklemek yerine accept'ten önce ekleyin. Zincir tünel arayüzü için zaten genel bir accept içeriyorsa, yeni kural onun önünde olmalıdır, aksi hâlde yalnızca süslemedir. Düzenlediğiniz dosyayı değil, ortaya çıkan sırayı kontrol edin, çünkü birkaç dosyadan birleştirilen bir kural kümesi hiçbiriyle örtüşmeyebilir. Ardından havuzdan bir test paketiyle doğrulayın.
sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.confÜçüncü komut dosyayı uygulamadan ayrıştırır ve sözdizimi hatalarını kesintiye dönüşmeden yakalar. Geri alma planıyla uygulayın, çünkü forward zincirindeki yanlış bir kural üzerinde çalıştığınız tüneli kesebilir.
Mevcut akışlar yeni kuralınızı umursamaz
Kural var olmadan önce oluşturulmuş bir conntrack girdisi önceki accept ile eşleşmeye devam eder. Bu yüzden yeni bir drop bazen yeni bağlantılar için çalışıyor gibi görünür ve test edilen bağlantı için hiçbir şey yapmaz.
Zincirin başındaki durum eşleşmesini okuyun. Kuralınızdan önce established ve related trafiği kabul ediyorsa, hâlihazırda sürmekte olan her akış kapanana kadar akmaya devam eder. Acil bir kural için genellikle istediğiniz davranış budur ve hemen kesilme beklediğinizde kafa karıştırıcıdır. Dağıtımdan önce hangi etkiyi istediğinize karar verin. Açık bir bağlantıyı yeniden kullanan bir test size yanlış hikâye anlatır.
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'İlk komut bir akışın olup olmadığını, ikincisi ise erken bir durum kuralının onu hâlâ kabul edip etmediğini gösterir. İkisi de salt okunurdur ve olay sırasında çalıştırmak güvenlidir.
Bu kural ne değildir
Kural bir alan adı kara listesi, bir IPv6 politikası veya tek bir uygulama hesabına yönelik bir kısıtlama değildir.
Bunların her biri kendi mekanizmasını gerektirir. Alan adı engellemesi adları çözmek zorundadır, ki bir paket filtresi bunu yapmaz. IPv6 trafiği kendi eşleşmesini gerektirir, çünkü bir ip ifadesi ip6 paketleri hakkında hiçbir şey söylemez. Uygulama düzeyindeki kısıtlama önek eşleşmesine değil, hizmete veya kimliği doğrulanmış bir proxy'ye aittir. Bu gereksinimleri ayrı tutmak, tek bir dar kuraldan dört iş istenmesini önler.
Bu kuralın sağladığı sözleşme kesindir: izin verilen bir havuzdan tek bir hedef önekine giden trafik reddedilir, ilgisiz ağ geçidi trafiği ise mevcut politikasını korur. Bu cümleyi kuralın yanına yazın, sonraki kişi ne için olduğunu bilecektir.