Repara el DNS dels convidats de libvirt bloquejat per un tallafoc VPN basat en marques

Els convidats de la xarxa libvirt per defecte resolen noms perfectament fins que puja la interfície WireGuard, i llavors cada consulta s'encalla al mateix lloc. dnsmasq encara escolta a 192.168.122.1:53, el convidat encara té aquesta adreça com a resolutor, i la consulta encara arriba. El que ha canviat és que la pròpia consulta ascendent de l'amfitrió, o la resposta a aquesta, ara és descartada per una regla que s'avalua abans que qualsevol cadena de filtratge que pensaríeu editar. La sortida és una marca aplicada prou aviat, en una connexió que la resposta hereta.

Els convidats perden el DNS en el moment que puja el túnel

Confirmeu la forma abans de canviar res. Baixeu el túnel, executeu dig @192.168.122.1 example.com des d'un convidat i mireu com respon. Pugeu el túnel, repetiu i mireu com expira. Aquest parell de resultats descarta una xarxa libvirt trencada, una adreça de resolutor incorrecta i un dnsmasq mort en un sol pas.

Després mireu el costat de l'amfitrió. Si dnsmasq registra la consulta i el seu reenviament ascendent, el paquet ha arribat i la fallada és a la sortida. Si dnsmasq no registra res, la consulta del convidat es descarta a l'entrada i l'excepció pertany a un hook diferent del que marca aquest article.

Per què una regla accept en una cadena posterior no s'activa mai

Un tallafoc VPN basat en marques decideix mirant la marca del paquet o la marca de la connexió, no la vostra adreça d'origen. Tot el que arriba a la interfície física sense la marca esperada es rebutja, i aquest rebuig passa al conjunt de regles que posseeix la prova de marca. Una línia ip saddr 192.168.122.0/24 accept afegida a una cadena posterior simplement no es consulta mai per a aquest paquet, i per això la regla òbvia sembla correcta i no canvia res.

Ampliar-la fins que alguna cosa funcioni és la segona trampa. Acceptar tota la subxarxa libvirt al camí d'entrada de l'amfitrió obre tots els serveis de l'amfitrió als convidats, quan la necessitat real és un sol port.

El mecanisme que fa possible una excepció estreta és el seguiment de connexions. Quan establiu ct mark en un paquet, el valor s'emmagatzema a l'entrada conntrack i no només al paquet, de manera que cada paquet d'aquella connexió el porta després, inclosa la resposta de l'amfitrió cap al convidat. Aquest és tot el truc: marqueu la petició una vegada i el camí de tornada ja està marcat.

Marqueu la consulta abans que la taula VPN la vegi

Poseu l'excepció a la seva pròpia taula perquè un lector posterior la pugui trobar sense analitzar les regles 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 és negatiu, cosa que col·loca aquesta cadena davant de les cadenes de filtratge ordinàries que el paquet VPN instal·la amb prioritat zero. L'ordre dels hooks és el que fa efectiva la regla; la mateixa regla en una cadena que s'ordena després de la cadena VPN és decoració.

El número de marca en si no és portable. Agafeu el valor que les regles VPN instal·lades accepten per al seu propi trànsit, llegiu-lo del conjunt de regles viu i feu-lo servir. Una marca incorrecta produeix una regla que es carrega neta, coincideix amb cada consulta i no admet res.

Mantingueu el forat de l'amplada del port 53

Tal com està escrit, això permet DNS de la subxarxa libvirt a l'amfitrió per TCP o UDP al port 53 i res més. No deixa que els convidats arribin a internet fora del túnel, i no deixa que l'amfitrió obri connexions cap als convidats. Si un convidat necessita més endavant un altre servei de l'amfitrió, afegiu una regla separada que anomeni aquest port de destinació en lloc de relaxar aquesta.

Sigueu honestos sobre què estau intercanviant. Un convidat que pot arribar a un resolutor també pot tunelitzar dades arbitràries a través de consultes DNS, i aquesta excepció és un buit deliberat a la frontera VPN, no una declaració que la xarxa local sigui de confiança. Restringir l'origen a 192.168.122.0/24 manté el buit lluny de qualsevol altra subxarxa local, i comptar consultes contra aquest origen és barat si l'amenaça us importa.

Feu que sobrevisqui a un reinici i demostreu les dues meitats

Una regla escrita en un indicador d'ordres desapareix al proper arrencada, i una regla carregada després que la interfície VPN ja passi trànsit perd la cursa a la primera connexió. Poseu la taula a la configuració persistent de nftables de l'amfitrió, o en una unitat ordenada abans del servei VPN, i comproveu l'ordre en lloc de suposar-lo.

La verificació necessita tres respostes separades. Confirmeu que la cadena està carregada i ordenada primera, confirmeu que l'entrada conntrack mostra la marca en totes dues direccions i confirmeu que una consulta del convidat retorna una adreça. Després confirmeu l'altra meitat: el trànsit web ordinari del convidat cap a un amfitrió públic encara falla mentre el túnel està baix o bloquejant. Si el DNS funciona i tota la resta filtra, la vostra regla és més àmplia que la de dalt.

Si les consultes encara fallen després que la marca estigui al lloc, resistiu l'impuls d'ampliar l'origen. Comproveu cap a on reenvia dnsmasq, si el resolutor del convidat apunta a 192.168.122.1 o a una adreça pública que algú ha escrit, i si la consulta arriba de fet a l'amfitrió. Marcar admet el paquet i res més, així que un mal ascendent o una xarxa virtual trencada continuen trencats per moltes regles que afegiu.