Popravite DNS gosta libvirt, ki ga blokira požarni zid VPN na oznakah

Gostje v privzetem omrežju libvirt brezhibno razrešujejo imena, dokler se ne pojavi vmesnik WireGuard, nato pa se vsako iskanje ustavi na istem mestu. dnsmasq še vedno posluša na 192.168.122.1:53, gost ima še vedno ta naslov kot razreševalnik in poizvedba še vedno prispe. Spremenilo se je to, da zdaj lastno nadrejeno poizvedbo gostitelja ali odgovor nanjo zavrže pravilo, ki se ovrednoti pred katero koli verigo filtrov, ki bi jo hoteli urediti. Izhod je oznaka, nameščena dovolj zgodaj, na povezavi, ki jo odgovor podeduje.

Gostje izgubijo DNS v trenutku, ko se tunel dvigne

Potrdite obliko, preden kar koli spremenite. Spustite tunel, zaženite dig @192.168.122.1 example.com z gosta in glejte, kako odgovarja. Dvignite tunel, ponovite in glejte, kako poteče. Ta par izidov v enem koraku izloči pokvarjeno omrežje libvirt, napačen naslov razreševalnika in mrtev dnsmasq.

Nato poglejte na stran gostitelja. Če dnsmasq beleži poizvedbo in njeno nadrejeno posredovanje, je paket prispel in napaka je na izhodu. Če dnsmasq ne beleži ničesar, se poizvedba gosta zavrže na vhodu in izjema spada na drug hook, ne na tistega, ki ga označuje ta članek.

Zakaj pravilo accept v poznejši verigi nikoli ne sproži

Požarni zid VPN na oznakah se odloča tako, da gleda oznako paketa ali oznako povezave, ne pa vašega izvornega naslova. Vse, kar prispe na fizični vmesnik brez pričakovane oznake, je zavrnjeno, in ta zavrnitev se zgodi v naboru pravil, ki ima v lasti preizkus oznake. ip saddr 192.168.122.0/24 accept vrstica, dodana v katero koli poznejšo verigo, se za ta paket preprosto nikoli ne upošteva, zato se očitno pravilo zdi pravilno in nič ne spremeni.

Širjenje, dokler nekaj ne deluje, je druga past. Sprejetje celotne podomrežja libvirt na vhodni poti gostitelja odpre vsako gostiteljevo storitev gostom, ko je dejanska potreba en vrata.

Mehanizem, ki omogoča ozko izjemo, je sledenje povezavam. Ko nastavite ct mark na paket, se vrednost shrani v vnos conntrack in ne le na paket, zato jo vsak paket te povezave pozneje nosi, vključno z odgovorom z gostitelja nazaj h gostu. To je vsa zvijača: zahtevo označite enkrat in povratna pot je že označena.

Označite poizvedbo, preden jo vidi tabela VPN

Postavite izjemo v lastno tabelo, da jo poznejši bralec najde brez razčlenjevanja pravil VPN:

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 je negativna, kar to verigo postavi pred običajne verige filtrov, ki jih paket VPN namesti s prioriteto nič. Prav vrstni red hookov naredi pravilo učinkovito; isto pravilo v verigi, ki se razvrsti za verigo VPN, je le okras.

Sama številka oznake ni prenosljiva. Vzemite vrednost, ki jo nameščena pravila VPN sprejmejo za svoj promet, jo preberite iz živega nabora pravil in uporabite to. Napačna oznaka ustvari pravilo, ki se naloži čisto, se ujema z vsako poizvedbo in ničesar ne spusti.

Naj bo luknja široka kot vrata 53

Kot je zapisano, to dovoljuje DNS iz podomrežja libvirt do gostitelja po TCP ali UDP na vratih 53 in nič drugega. Gostom ne dovoli doseči interneta zunaj tunela in gostitelju ne dovoli odpirati povezav proti gostom. Če bo gost pozneje potreboval drugo gostiteljevo storitev, dodajte ločeno pravilo, ki imenuje ta ciljna vrata, namesto da bi to sprostili.

Bodite pošteni glede tega, kaj menjate. Gost, ki lahko doseže razreševalnik, lahko tudi tunelira poljubne podatke skozi poizvedbe DNS, in ta izjema je namerna vrzel v meji VPN, ne pa izjava, da je lokalno omrežje zaupanja vredno. Omejitev vira na 192.168.122.0/24 drži vrzel stran od vsakega drugega lokalnega podomrežja, število poizvedb s tega vira pa je poceni, če vam grožnja kaj pomeni.

Poskrbite, da bo preživelo ponovni zagon, in dokažite obe polovici

Pravilo, vtipkano v lupini, izgine ob naslednjem zagonu, pravilo, naloženo potem, ko vmesnik VPN že prepušča promet, pa izgubi tekmo pri prvi povezavi. Postavite tabelo v trajno konfiguracijo nftables gostitelja ali v enoto, razvrščeno pred storitvijo VPN, in vrstni red preverite, namesto da bi ga predpostavljali.

Preverjanje potrebuje tri ločene odgovore. Potrdite, da je veriga naložena in razvrščena prva, potrdite, da vnos conntrack kaže oznako v obe smeri, in potrdite, da iskanje z gosta vrne naslov. Nato potrdite drugo polovico: običajen spletni promet gosta do javnega gostitelja še vedno ne uspe, medtem ko je tunel spuščen ali blokira. Če DNS deluje in vse drugo uhaja, je vaše pravilo širše od zgornjega.

Če iskanja še vedno ne uspejo, potem ko je oznaka postavljena, se uprite želji po razširitvi vira. Preverite, kam posreduje dnsmasq, ali razreševalnik gosta kaže na 192.168.122.1 ali na javni naslov, ki ga je nekdo vtipkal, in ali poizvedba sploh doseže gostitelja. Označevanje spusti paket in nič drugega, zato slab nadrejeni strežnik ali pokvarjeno navidezno omrežje ostaneta pokvarjena, ne glede na to, koliko pravil dodate.