A libvirt vendég DNS-jének javítása, amelyet jelölésalapú VPN-tűzfal blokkol

A jelölésalapú VPN-tűzfal eldobja a vendég DNS-ét, mielőtt bármely szűrőlánc látná. Egy mangle prioritású szabály megjelöli a lekérdezést és a válaszát, anélkül hogy kinyitná a LAN-t.

A vendégek az alapértelmezett libvirt-hálózaton tökéletesen oldanak fel neveket, amíg a WireGuard-interfész fel nem jön, és akkor minden lekérdezés ugyanazon a ponton akad el. dnsmasq még mindig a 192.168.122.1:53 címen figyel, a vendégnek még mindig ez a cím a feloldója, és a lekérdezés még mindig megérkezik. Ami megváltozott, hogy a gazdagép saját felfelé irányuló lekérdezését, vagy arra a választ, most egy olyan szabály dobja el, amelyet minden olyan szűrőlánc előtt értékelnek, amelyet szerkeszteni gondolnál. A kiút egy kellően korán alkalmazott jelölés, olyan kapcsolaton, amelyet a válasz örököl.

A vendégek elveszítik a DNS-t abban a pillanatban, amikor az alagút feljön

Erősítsd meg a formát, mielőtt bármit változtatnál. Vedd le az alagutat, futtasd a dig @192.168.122.1 example.com parancsot egy vendégből, és nézd meg, hogy válaszol. Hozd fel az alagutat, ismételd meg, és nézd meg, hogy lejár. Ez az eredménypár egyetlen lépésben kizárja a törött libvirt-hálózatot, a rossz feloldócímet és a halott dnsmasq-t.

Aztán nézd meg a gazdagép oldalát. Ha a dnsmasq naplózza a lekérdezést és annak felfelé továbbítását, a csomag megérkezett, és a hiba a kimeneten van. Ha a dnsmasq semmit nem naplóz, a vendég lekérdezése a bemeneten dobódik el, és a kivétel egy másik hookhoz tartozik, mint amelyet ez a cikk megjelöl.

Miért nem lép soha életbe egy accept szabály egy későbbi láncban

A jelölésalapú VPN-tűzfal a csomagjelölés vagy a kapcsolatjelölés alapján dönt, nem a forráscímed alapján. Minden, ami a fizikai interfészen a várt jelölés nélkül érkezik, elutasításra kerül, és ez az elutasítás a jelöléstesztet birtokló szabálykészletben történik. Egy későbbi lánchoz hozzáadott ip saddr 192.168.122.0/24 accept sor egyszerűen soha nem kerül figyelembevételre ehhez a csomaghoz, ezért tűnik helyesnek a kézenfekvő szabály, és nem változtat semmit.

A szélesítés addig, amíg valami működik, a második csapda. A teljes libvirt-alhálózat elfogadása a gazdagép bemeneti útvonalán minden gazdagépszolgáltatást megnyit a vendégek előtt, miközben a valódi igény egyetlen port.

A szűk kivételt lehetővé tevő mechanizmus a kapcsolatkövetés. Amikor ct mark-et állítasz be egy csomagon, az érték a conntrack-bejegyzésben tárolódik, nem csak a csomagon, így a kapcsolat minden csomagja ezután hordozza, beleértve a gazdagéptől a vendéghez menő választ is. Ez az egész trükk: jelöld meg a kérést egyszer, és a visszaút már meg van jelölve.

Jelöld meg a lekérdezést, mielőtt a VPN-tábla látja

Tedd a kivételt a saját táblájába, hogy egy későbbi olvasó megtalálja anélkül, hogy elemezné a VPN-szabályokat:

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 negatív, ami ezt a láncot a VPN-csomag által nulla prioritáson telepített szokásos szűrőláncok elé helyezi. A hookok sorrendje teszi hatékonnyá a szabályt; ugyanaz a szabály egy VPN-lánc után rendezett láncban csak díszítés.

Maga a jelölésszám nem hordozható. Vedd azt az értéket, amelyet a telepített VPN-szabályok a saját forgalmukra elfogadnak, olvasd ki az élő szabálykészletből, és használd. A rossz jelölés olyan szabályt ad, amely tisztán betöltődik, minden lekérdezésre illeszkedik, és semmit nem enged át.

Tartsd a lyukat az 53-as port szélességében

Ahogy le van írva, ez DNS-t enged a libvirt-alhálózatból a gazdagéphez TCP vagy UDP 53-as porton, és semmi mást. Nem engedi a vendégeknek elérni az internetet az alagúton kívül, és nem engedi a gazdagépnek kapcsolatokat nyitni a vendégek felé. Ha egy vendégnek később más gazdagépszolgáltatásra van szüksége, adj hozzá külön szabályt, amely megnevezi azt a célportot, ahelyett hogy ezt lazítanád.

Légy őszinte azzal kapcsolatban, mit cserélsz el. Az a vendég, amely elér egy feloldót, tetszőleges adatot is tud alagutazni DNS-lekérdezéseken keresztül, és ez a kivétel szándékos rés a VPN-határon, nem annak kijelentése, hogy a helyi hálózat megbízható. A forrás 192.168.122.0/24-re korlátozása távol tartja a rést minden más helyi alhálózattól, és a lekérdezések számolása e forrás ellen olcsó, ha a fenyegetés számít neked.

Tedd túlélővé újraindítás után, és bizonyítsd mindkét felét

A shell-parancssorba gépelt szabály eltűnik a következő indításkor, és a VPN-interfész forgalmának megindulása után betöltött szabály elveszíti a versenyt az első kapcsolatnál. Tedd a táblát a gazdagép tartós nftables-konfigurációjába, vagy egy VPN-szolgáltatás elé rendezett unitba, és ellenőrizd a sorrendet, ahelyett hogy feltételeznéd.

Az ellenőrzéshez három külön válasz kell. Erősítsd meg, hogy a lánc be van töltve és elsőként rendezett, erősítsd meg, hogy a conntrack-bejegyzés mindkét irányban mutatja a jelölést, és erősítsd meg, hogy egy vendég lekérdezése címet ad vissza. Utána erősítsd meg a másik felét: a vendég szokásos webforgalma egy nyilvános gazdagéphez továbbra is meghiúsul, amíg az alagút le van állítva vagy blokkol. Ha a DNS működik, és minden más szivárog, a szabályod szélesebb a fentinél.

Ha a lekérdezések a jelölés behelyezése után is meghiúsulnak, állj ellen a forrás szélesítése iránti késztetésnek. Ellenőrizd, hova továbbít a dnsmasq, hogy a vendég feloldója a 192.168.122.1-re mutat-e vagy egy nyilvános címre, amelyet valaki beírt, és hogy a lekérdezés egyáltalán eléri-e a gazdagépet. A jelölés átengedi a csomagot és semmi mást, így a rossz felfelé irányuló kapcsolat vagy a törött virtuális hálózat törött marad, akárhány szabályt adsz hozzá.

Kapcsolódó cikkek