Ret DNS for libvirt-gæster, der blokeres af en markbaseret VPN-firewall

En markbaseret VPN-firewall smider gæstens DNS væk, før nogen filterkæde ser den. Én regel med mangle-prioritet markerer forespørgslen og dens svar uden at åbne dit LAN.

Gæster på standard-libvirt-netværket opløser navne perfekt, indtil WireGuard-interfacet kommer op, og så går hvert opslag i stå samme sted. dnsmasq lytter stadig på 192.168.122.1:53, gæsten har stadig den adresse som resolver, og forespørgslen ankommer stadig. Det, der er ændret, er, at værtens egen upstream-forespørgsel, eller svaret på den, nu smides væk af en regel, der evalueres før enhver filterkæde, du ville overveje at redigere. Vejen ud er et mærke anvendt tidligt nok, på en forbindelse som svaret arver.

Gæster mister DNS i det øjeblik tunnelen kommer op

Bekræft formen, før du ændrer noget. Tag tunnelen ned, kør dig @192.168.122.1 example.com fra en gæst, og se den svare. Tag tunnelen op, gentag, og se den gå i timeout. Det par resultater udelukker et ødelagt libvirt-netværk, en forkert resolveradresse og en død dnsmasq i ét trin.

Se derefter på værtssiden. Hvis dnsmasq logger forespørgslen og dens upstream-videresendelse, er pakken ankommet, og fejlen er på udgangen. Hvis dnsmasq slet ikke logger noget, smides gæstens forespørgsel væk på indgangen, og undtagelsen hører til en anden hook end den, denne artikel markerer.

Hvorfor en accept-regel i en senere kæde aldrig udløses

En markbaseret VPN-firewall beslutter ved at se på pakkemarket eller forbindelsesmarket, ikke på din kildeaddresse. Alt, der ankommer på det fysiske interface uden det forventede mærke, afvises, og den afvisning sker i det regelsæt, der ejer marktesten. En ip saddr 192.168.122.0/24 accept-linje tilføjet til en senere kæde bliver simpelthen aldrig konsulteret for den pakke, og det er derfor, den oplagte regel ser rigtig ud og ikke ændrer noget.

At udvide den, indtil noget virker, er den anden fælde. At acceptere hele libvirt-undernettet i værtens inputsti åbner hver værtservice for gæsterne, mens det faktiske behov er én port.

Mekanismen, der gør en snæver undtagelse mulig, er forbindelsessporing. Når du sætter ct mark på en pakke, gemmes værdien på conntrack-posten i stedet for kun på pakken, så hver pakke i den forbindelse bærer den bagefter, inklusive svaret fra værten tilbage til gæsten. Det er hele trickingen: marker anmodningen én gang, og returvejen er allerede markeret.

Markér forespørgslen, før VPN-tabellen ser den

Læg undtagelsen i sin egen tabel, så en senere læser kan finde den uden at parse VPN-reglerne:

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 er negativ, hvilket placerer denne kæde foran de almindelige filterkæder, som VPN-pakken installerer ved prioritet nul. Hook-rækkefølgen er det, der gør reglen effektiv; den samme regel i en kæde, der sorteres efter VPN-kæden, er dekoration.

Selve marktallet er ikke portabelt. Tag den værdi, de installerede VPN-regler accepterer for deres egen trafik, læs den ud af det levende regelsæt, og brug den. Et forkert mærke giver en regel, der indlæses rent, matcher hver forespørgsel og ikke tillader noget.

Hold hullet på størrelse med port 53

Som skrevet tillader dette DNS fra libvirt-undernettet til værten over TCP eller UDP port 53 og intet andet. Det lader ikke gæster nå internettet uden for tunnelen, og det lader ikke værten åbne forbindelser mod gæster. Hvis en gæst senere har brug for en anden værtservice, skal du tilføje en separat regel, der navngiver den destinationsport, i stedet for at lempe denne.

Vær ærlig om, hvad du bytter. En gæst, der kan nå en resolver, kan også tunnelere vilkårlige data gennem DNS-forespørgsler, og denne undtagelse er et bevidst hul i VPN-grænsen snarere end en erklæring om, at det lokale netværk er betroet. At begrænse kilden til 192.168.122.0/24 holder hullet væk fra alle andre lokale undernet, og det er billigt at tælle forespørgsler mod den kilde, hvis truslen betyder noget for dig.

Få den til at overleve genstart, og bevis begge halvdele

En regel, der skrives i en shell-prompt, forsvinder ved næste opstart, og en regel, der indlæses, efter at VPN-interfacet allerede sender trafik, taber kapløbet på den første forbindelse. Læg tabellen i værtens vedvarende nftables-konfiguration eller i en unit, der er bestilt før VPN-tjenesten, og kontrollér rækkefølgen i stedet for at antage den.

Verifikation kræver tre separate svar. Bekræft, at kæden er indlæst og bestilt først, bekræft, at conntrack-posten viser mærket i begge retninger, og bekræft, at et gæsteopslag returnerer en adresse. Bekræft derefter den anden halvdel: almindelig gæstewebtrafik til en offentlig vært fejler stadig, mens tunnelen er nede eller blokerer. Hvis DNS virker, og alt andet lækker, er din regel bredere end den ovenfor.

Hvis opslag stadig fejler, efter at mærket er på plads, skal du modstå trangen til at udvide kilden. Kontrollér, hvad dnsmasq videresender til, om gæstens resolver peger på 192.168.122.1 eller på en offentlig adresse, som nogen har indtastet, og om forespørgslen overhovedet når værten. Mærkning tillader pakken og intet andet, så en dårlig upstream eller et ødelagt virtuelt netværk forbliver ødelagt, uanset hvor mange regler du tilføjer.

Relaterede artikler