Reparer gjeste-DNS i libvirt som vert blokkert av ein markbasert VPN-brannmur

Gjester på standard libvirt-nettverket slår opp namn heilt fint heilt til WireGuard-grensesnittet kjem opp, og då stoppar kvar oppslag på same staden. dnsmasq lyttar framleis på 192.168.122.1:53, gjesten har framleis den adressa som resolver, og spørjinga kjem framleis fram. Det som er endra, er at verten si eiga oppstraumsspørjing, eller svaret på henne, no blir droppa av ein regel som blir evaluert før kva som helst filterkjede du ville trudd du måtte redigere. Vegen ut er eit merke som blir sett tidleg nok, på ei tilkopling som svaret arvar.

Gjestene mistar DNS i det augneblunken tunnelen kjem opp

Stadfest forma før du endrar noko. Ta tunnelen ned, køyr dig @192.168.122.1 example.com frå ein gjest, og sjå at han svarar. Ta tunnelen opp, gjenta, og sjå at han timar ut. Det paret med resultat utelukkar eit øydelagt libvirt-nettverk, ei feil resolveradresse og ein daud dnsmasq i eitt steg.

Sjå så på vertssida. Viss dnsmasq loggar spørjinga og vidaresendinga oppstraums, kom pakken fram og feilen ligg på egress. Viss dnsmasq aldri loggar noko, blir gjestespørjinga droppa på ingress, og unntaket høyrer heime på ein annan krok enn den denne artikkelen merkar.

Kvifor ein accept-regel i ein seinare kjede aldri blir utløyst

Ein markbasert VPN-brannmur avgjer ved å sjå på pakkemerket eller tilkoplingsmerket, ikkje på kildeadressa di. Alt som kjem inn på det fysiske grensesnittet utan det venta merket, blir avvist, og den avvisinga skjer i regelsettet som eig merketesten. ip saddr 192.168.122.0/24 accept linje lagd til i ein eller annan seinare kjede blir rett og slett aldri konsultert for den pakken, og difor ser den opplagte regelen riktig ut og endrar ingenting.

Å utvide han til noko verkar, er den andre fella. Å akseptere heile libvirt-subnettet i input-stien til verten opnar kvar vertsteneste for gjestene, når det faktiske behovet er éin port.

Mekanismen som gjer eit smalt unntak mogleg, er tilkoplingsoppfølging. Når du set ct mark på ein pakke, blir verdien lagra på conntrack-oppføringa og ikkje berre på pakken, så kvar pakke i den tilkoplinga ber han etterpå, inkludert svaret frå verten tilbake til gjesten. Det er heile trikset: merk førespurnaden éin gong, og returvegen er allereie merka.

Merk spørjinga før VPN-tabellen ser henne

Legg unntaket i sin eigen tabell, så ein seinare lesar kan finne det utan å parse VPN-reglane:

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, noko som plasserer denne kjeda framfor dei vanlege filterkjedene VPN-pakken installerer ved prioritet null. Krok-rekkjefølgja er det som gjer regelen effektiv; den same regelen i ei kjede som sorterer etter VPN-kjeda, er berre dekorasjon.

Sjølve merketalet er ikkje portabelt. Ta verdien dei installerte VPN-reglane godtek for sin eigen trafikk, les han ut av det levande regelsettet, og bruk han. Eit feil merke gir ein regel som blir lasta reint, matchar kvar spørjing og slepp ingenting inn.

Hald holet på breidda av port 53

Som skrive tillèt dette DNS frå libvirt-subnettet til verten over TCP eller UDP port 53 og ingenting anna. Det lèt ikkje gjestene nå internett utanfor tunnelen, og det lèt ikkje verten opne tilkoplingar mot gjestene. Treng ein gjest ei anna vertsteneste seinare, legg til ein eigen regel som nemner den destinasjonsporten i staden for å lempe på denne.

Ver ærleg om kva du byter bort. Ein gjest som kan nå ein resolver, kan også tunnelere vilkårlege data gjennom DNS-spørjingar, og dette unntaket er eit medvite hol i VPN-grensa og ikkje ei fråsegn om at det lokale nettverket er til å stole på. Å avgrense kjelda til 192.168.122.0/24 held holet borte frå alle andre lokale subnett, og å telje spørjingar mot den kjelda er billeg viss trugselen betyr noko for deg.

Sørg for at det overlever omstart, og prov begge halvdelar

Ein regel skriven på ein shell-prompt forsvinn ved neste oppstart, og ein regel som blir lasta etter at VPN-grensesnittet allereie sender trafikk, tapar kappløpet på den første tilkoplinga. Legg tabellen i den vedvarande nftables-konfigurasjonen til verten, eller i ei eining ordna før VPN-tenesta, og kontroller rekkjefølgja i staden for å anta henne.

Verifisering treng tre separate svar. Stadfest at kjeda er lasta og ordna først, stadfest at conntrack-oppføringa viser merket i begge retningar, og stadfest at eit gjesteoppslag returnerer ei adresse. Stadfest så den andre halvdelen: vanleg gjestetrafikk til ein offentleg vert feilar framleis medan tunnelen er nede eller blokkerer. Viss DNS verkar og alt anna lek, er regelen din breiare enn den ovanfor.

Viss oppslag framleis feilar etter at merket er på plass, motstå trongen til å utvide kjelda. Sjekk kva dnsmasq vidaresender til, om resolveren til gjesten peikar på 192.168.122.1 eller på ei offentleg adresse nokon har skrive inn, og om spørjinga i det heile når verten. Merking slepp pakken inn og ingenting anna, så ein dårleg oppstraum eller eit øydelagt virtuelt nettverk blir verande øydelagt same kor mange reglar du legg til.