Marka tabanlı VPN güvenlik duvarının engellediği libvirt konuk DNS'ini düzeltin

Varsayılan libvirt ağındaki konuklar, WireGuard arayüzü gelene kadar adları kusursuz çözer ve sonra her arama aynı yerde takılır. dnsmasq hâlâ 192.168.122.1:53 üzerinde dinliyor, konuğun çözümleyicisi hâlâ o adres, ve sorgu hâlâ geliyor. Değişen şey, ana makinenin kendi üst sorgusu ya da ona verilen yanıtın artık, düzenlemeyi düşüneceğiniz herhangi bir filtre zincirinden önce değerlendirilen bir kural tarafından düşürülmesi. Çıkış yolu, yanıtın devraldığı bir bağlantı üzerinde yeterince erken uygulanan bir işaret.

Konuklar DNS'i tünel kalktığı anda kaybeder

Herhangi bir şeyi değiştirmeden önce şekli doğrulayın. Tüneli indirin, bir konuktan dig @192.168.122.1 example.com çalıştırın ve yanıt verdiğini görün. Tüneli kaldırın, tekrarlayın ve zaman aşımına uğradığını görün. Bu iki sonuç, bozuk bir libvirt ağını, yanlış çözümleyici adresini ve ölü bir dnsmasq'ı tek adımda eler.

Sonra ana makine tarafına bakın. dnsmasq sorguyu ve üst yönlendirmesini günlüğe yazıyorsa paket gelmiş ve hata çıkışta. dnsmasq hiçbir şey yazmıyorsa konuk sorgusu girişte düşürülüyor ve istisna bu makalenin işaretlediği kancadan farklı bir kancaya ait.

Sonraki bir zincirdeki accept kuralı neden hiç tetiklenmez

Marka tabanlı bir VPN güvenlik duvarı, kaynak adresinize değil, paket markasına ya da bağlantı markasına bakarak karar verir. Fiziksel arayüze beklenen marka olmadan gelen her şey reddedilir ve bu ret, marka testine sahip olan kural kümesinde gerçekleşir. ip saddr 192.168.122.0/24 accept satırı daha sonraki herhangi bir zincire eklendiğinde o paket için hiçbir zaman dikkate alınmaz, bu yüzden apaçık görünen kural doğru görünür ve hiçbir şeyi değiştirmez.

Bir şey çalışana kadar genişletmek ikinci tuzaktır. Tüm libvirt alt ağını ana makinenin giriş yolunda kabul etmek, gerçek ihtiyaç tek bir bağlantı noktasıyken konuklara ana makinenin her hizmetini açar.

Dar bir istisnayı mümkün kılan mekanizma bağlantı izlemedir. Bir pakete ct mark ayarladığınızda değer yalnızca pakete değil conntrack kaydına da yazılır, böylece o bağlantıdaki her paket sonrasında onu taşır; ana makineden konuğa dönen yanıt da dahil. Bütün hile budur: isteği bir kez işaretleyin, dönüş yolu zaten işaretlidir.

Sorguyu VPN tablosu görmeden işaretleyin

İstisnayı kendi tablosuna koyun ki sonraki bir okuyucu VPN kurallarını ayrıştırmadan bulabilsin:

table inet allowedLocal {
  chain guest_dns {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
      th dport 53 ct mark set 0x00000f41
  }
}

priority mangle negatiftir, bu da bu zinciri VPN paketinin sıfır önceliğinde kurduğu olağan filtre zincirlerinin önüne koyar. Kuralı etkili kılan kanca sırasıdır; VPN zincirinden sonra sıralanan bir zincirdeki aynı kural yalnızca süstür.

Marka numarasının kendisi taşınabilir değildir. Kurulu VPN kurallarının kendi trafiği için kabul ettiği değeri alın, canlı kural kümesinden okuyun ve onu kullanın. Yanlış marka, temiz yüklenen, her sorguyla eşleşen ve hiçbir şeyi içeri almayan bir kural üretir.

Deliği 53 numaralı bağlantı noktası genişliğinde tutun

Yazıldığı gibi bu, libvirt alt ağından ana makineye TCP veya UDP 53 numaralı bağlantı noktası üzerinden DNS'e izin verir, başka hiçbir şeye değil. Konukların tünel dışında internete ulaşmasına izin vermez ve ana makinenin konuklara doğru bağlantı açmasına izin vermez. Bir konuk sonradan başka bir ana makine hizmetine ihtiyaç duyarsa, bu kuralı gevşetmek yerine o hedef bağlantı noktasını adlandıran ayrı bir kural ekleyin.

Neyi değiştiğiniz konusunda dürüst olun. Bir çözümleyiciye ulaşabilen konuk, DNS sorguları üzerinden keyfî veri de tünelleebilir ve bu istisna VPN sınırında bilinçli bir boşluktur, yerel ağın güvenilir olduğu beyanı değildir. Kaynağı 192.168.122.0/24 ile sınırlamak o boşluğu diğer her yerel alt ağdan uzak tutar ve tehdit sizin için önemliyse o kaynağa karşı sorguları saymak ucuzdur.

Yeniden başlatmadan sonra da kalmasını sağlayın ve iki yarıyı da kanıtlayın

Bir kabuk istemine yazılan kural sonraki açılışta kaybolur ve VPN arayüzü zaten trafik geçirirken yüklenen kural ilk bağlantıda yarışı kaybeder. Tabloyu ana makinenin kalıcı nftables yapılandırmasına ya da VPN hizmetinden önce sıralanan bir birime koyun ve sırayı varsaymak yerine denetleyin.

Doğrulama üç ayrı yanıt gerektirir. Zincirin yüklendiğini ve ilk sırada olduğunu doğrulayın, conntrack kaydının markayı iki yönde gösterdiğini doğrulayın ve konuk aramasının bir adres döndürdüğünü doğrulayın. Sonra diğer yarıyı doğrulayın: konuğun genel bir ana makineye giden olağan web trafiği, tünel inikken veya engellerken hâlâ başarısız olur. DNS çalışıyor ve geri kalan her şey sızıyorsa kuralınız yukarıdakinden daha geniştir.

Marka yerleştikten sonra aramalar hâlâ başarısız oluyorsa kaynağı genişletme dürtüsüne karşı koyun. dnsmasq'ın nereye yönlendirdiğini, konuğun çözümleyicisinin 192.168.122.1 adresini mi yoksa birinin yazdığı genel bir adresi mi gösterdiğini ve sorgunun ana makineye hiç ulaşıp ulaşmadığını denetleyin. İşaretleme paketi içeri alır ve başka hiçbir şeyi almaz, bu yüzden kötü bir üst kaynak ya da bozuk bir sanal ağ, kaç kural eklerseniz ekleyin bozuk kalır.