Fiks gjeste-DNS i libvirt som blokkeres av en markbasert VPN-brannmur

Gjester på standard libvirt-nettverket slår opp navn helt fint helt til WireGuard-grensesnittet kommer opp, og da stopper hvert oppslag på samme sted. dnsmasq lytter fortsatt på 192.168.122.1:53, gjesten har fortsatt den adressen som resolver, og spørringen kommer fortsatt fram. Det som er endret, er at vertens egen oppstrømsspørring, eller svaret på den, nå droppes av en regel som evalueres før noen filterkjede du ville trodd du måtte redigere. Veien ut er et merke som settes tidlig nok, på en tilkobling som svaret arver.

Gjestene mister DNS i det øyeblikket tunnelen kommer opp

Bekreft formen før du endrer noe. Ta tunnelen ned, kjør dig @192.168.122.1 example.com fra en gjest, og se at den svarer. Ta tunnelen opp, gjenta, og se at den timer ut. Det paret med resultater utelukker et ødelagt libvirt-nettverk, en feil resolveradresse og en død dnsmasq i ett steg.

Se så på vertssiden. Hvis dnsmasq logger spørringen og videresendingen oppstrøms, kom pakken fram og feilen ligger på egress. Hvis dnsmasq aldri logger noe, droppes gjestespørringen på ingress, og unntaket hører hjemme på en annen krok enn den denne artikkelen merker.

Hvorfor en accept-regel i en senere kjede aldri utløses

En markbasert VPN-brannmur bestemmer ved å se på pakkemerket eller tilkoblingsmerket, ikke på kildeadressen din. Alt som kommer inn på det fysiske grensesnittet uten det forventede merket, avvises, og den avvisningen skjer i regelsettet som eier merketesten. ip saddr 192.168.122.0/24 accept linje lagt til i en eller annen senere kjede blir rett og slett aldri konsultert for den pakken, og derfor ser den opplagte regelen riktig ut og endrer ingenting.

Å utvide den til noe virker, er den andre fellen. Å akseptere hele libvirt-subnettet i vertens input-sti åpner hver vertstjeneste for gjestene, når det faktiske behovet er én port.

Mekanismen som gjør et smalt unntak mulig, er tilkoblingssporing. Når du setter ct mark på en pakke, lagres verdien på conntrack-oppføringen og ikke bare på pakken, så hver pakke i den tilkoblingen bærer den etterpå, inkludert svaret fra verten tilbake til gjesten. Det er hele trikset: merk forespørselen én gang, og returveien er allerede merket.

Merk spørringen før VPN-tabellen ser den

Legg unntaket i sin egen tabell, så en senere leser kan finne det uten å parse VPN-reglene:

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, noe som plasserer denne kjeden foran de vanlige filterkjedene VPN-pakken installerer ved prioritet null. Krok-rekkefølgen er det som gjør regelen effektiv; den samme regelen i en kjede som sorteres etter VPN-kjeden, er bare dekorasjon.

Selve merkentallet er ikke portabelt. Ta verdien de installerte VPN-reglene godtar for sin egen trafikk, les den ut av det levende regelsettet, og bruk den. Et feil merke gir en regel som lastes rent, matcher hver spørring og slipper ingenting inn.

Hold hullet på bredden av port 53

Som skrevet tillater dette DNS fra libvirt-subnettet til verten over TCP eller UDP port 53 og ingenting annet. Det lar ikke gjestene nå internett utenfor tunnelen, og det lar ikke verten åpne tilkoblinger mot gjestene. Trenger en gjest en annen vertstjeneste senere, legg til en egen regel som navngir den destinasjonsporten i stedet for å lempe på denne.

Vær ærlig om hva du bytter bort. En gjest som kan nå en resolver, kan også tunnelere vilkårlige data gjennom DNS-spørringer, og dette unntaket er et bevisst hull i VPN-grensen og ikke en erklæring om at det lokale nettverket er til å stole på. Å begrense kilden til 192.168.122.0/24 holder hullet borte fra alle andre lokale subnett, og å telle spørringer mot den kilden er billig hvis trusselen betyr noe for deg.

Sørg for at det overlever omstart, og bevis begge halvdeler

En regel skrevet på en shell-prompt forsvinner ved neste oppstart, og en regel som lastes etter at VPN-grensesnittet allerede sender trafikk, taper kappløpet på den første tilkoblingen. Legg tabellen i vertens vedvarende nftables-konfigurasjon, eller i en enhet ordnet før VPN-tjenesten, og kontroller rekkefølgen i stedet for å anta den.

Verifisering trenger tre separate svar. Bekreft at kjeden er lastet og ordnet først, bekreft at conntrack-oppføringen viser merket i begge retninger, og bekreft at et gjesteoppslag returnerer en adresse. Bekreft så den andre halvdelen: vanlig gjestetrafikk til en offentlig vert feiler fortsatt mens tunnelen er nede eller blokkerer. Hvis DNS virker og alt annet lekker, er regelen din bredere enn den ovenfor.

Hvis oppslag fortsatt feiler etter at merket er på plass, motstå trangen til å utvide kilden. Sjekk hva dnsmasq videresender til, om gjestens resolver peker på 192.168.122.1 eller på en offentlig adresse noen har skrevet inn, og om spørringen i det hele tatt når verten. Merking slipper pakken inn og ingenting annet, så en dårlig oppstrøm eller et ødelagt virtuelt nettverk forblir ødelagt uansett hvor mange regler du legger til.