Arranxar o DNS dos convidados de libvirt bloqueado por unha devasa VPN baseada en marcas

Unha devasa VPN baseada en marcas descarta o DNS dos convidados antes de que o vexa calquera cadea de filtrado. Unha regra con prioridade mangle marca a consulta e a súa resposta, sen abrir a túa LAN.

Os convidados da rede libvirt predeterminada resolven nomes perfectamente ata que sobe a interface WireGuard, e entón cada consulta atasca no mesmo punto. dnsmasq segue escoitando en 192.168.122.1:53, o convidado segue tendo ese enderezo como resolutor, e a consulta segue chegando. O que cambiou é que a propia consulta ascendente do anfitrión, ou a resposta a ela, agora é descartada por unha regra que se avalia antes que calquera cadea de filtrado que pensases editar. A saída é unha marca aplicada con suficiente antelación, nunha conexión que a resposta herda.

Os convidados perden o DNS no momento en que sobe o túnel

Confirma a forma antes de cambiar nada. Baixa o túnel, executa dig @192.168.122.1 example.com desde un convidado e mírao responder. Sobe o túnel, repite e mírao esgotar o tempo. Ese par de resultados descarta unha rede libvirt rota, un enderezo de resolutor incorrecto e un dnsmasq morto nun só paso.

Despois mira o lado do anfitrión. Se dnsmasq rexistra a consulta e o seu reenvío ascendente, o paquete chegou e o fallo está na saída. Se dnsmasq non rexistra nada, a consulta do convidado estase a descartar na entrada e a excepción pertence a un hook distinto do que marca este artigo.

Por que unha regra accept nunha cadea posterior nunca se dispara

Unha devasa VPN baseada en marcas decide mirando a marca do paquete ou a marca da conexión, non o teu enderezo de orixe. Todo o que chega á interface física sen a marca esperada é rexeitado, e ese rexeitamento ocorre no conxunto de regras que posúe a proba de marca. Unha liña ip saddr 192.168.122.0/24 accept engadida a algunha cadea posterior simplemente nunca se consulta para ese paquete, por iso a regra obvia parece correcta e non cambia nada.

Amplialo ata que algo funcione é a segunda trampa. Aceptar toda a subrede libvirt na ruta de entrada do anfitrión abre todos os servizos do anfitrión aos convidados, cando a necesidade real é un só porto.

O mecanismo que fai posible unha excepción estreita é o seguimento de conexións. Cando estabeleces ct mark nun paquete, o valor gárdase na entrada de conntrack e non só no paquete, así que cada paquete desa conexión lévao despois, incluída a resposta do anfitrión de volta ao convidado. Ese é todo o truco: marca a petición unha vez e a ruta de volta xa está marcada.

Marca a consulta antes de que a táboa VPN a vexa

Pon a excepción na súa propia táboa para que un lector posterior poida atopala sen analizar as regras 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 é negativo, o que coloca esta cadea diante das cadeas de filtrado ordinarias que o paquete VPN instala con prioridade cero. A orde dos hooks é o que fai efectiva a regra; a mesma regra nunha cadea que se ordena despois da cadea VPN é decoración.

O número de marca en si non é portátil. Toma o valor que as regras VPN instaladas aceptan para o seu propio tráfico, leuno do conxunto de regras vivo e úsao. Unha marca incorrecta produce unha regra que se carga limpiamente, coincide con cada consulta e non admite nada.

Mantén o burato do largo do porto 53

Tal como está escrito, isto permite DNS da subrede libvirt ao anfitrión por TCP ou UDP no porto 53 e nada máis. Non deixa que os convidados cheguen a internet fóra do túnel, e non deixa que o anfitrión abra conexións cara aos convidados. Se un convidado necesita máis adiante outro servizo do anfitrión, engade unha regra separada que nomee ese porto de destino en lugar de relaxar esta.

Sé honesto sobre o que estás a trocar. Un convidado que pode alcanzar un resolutor tamén pode tunelizar datos arbitrarios a través de consultas DNS, e esta excepción é un oco deliberado na fronteira VPN, non unha afirmación de que a rede local sexa de confianza. Restrinxir a orixe a 192.168.122.0/24 mantén o oco lonxe de calquera outra subrede local, e contar consultas contra esa orixe é barato se a ameaza te importa.

Fai que sobreviva a un reinicio e demostra ambas as metades

Unha regra escrita nun indicador de shell desaparece no seguinte arranque, e unha regra cargada despois de que a interface VPN xa pase tráfico perde a carreira na primeira conexión. Pon a táboa na configuración persistente de nftables do anfitrión, ou nunha unidade ordenada antes do servizo VPN, e comproba a orde en lugar de supoñela.

A verificación necesita tres respostas separadas. Confirma que a cadea está cargada e ordenada primeiro, confirma que a entrada de conntrack mostra a marca en ambas as direccións e confirma que unha busca do convidado devolve un enderezo. Despois confirma a outra metade: o tráfico web ordinario do convidado a un anfitrión público segue fallando mentres o túnel está baixo ou bloqueando. Se o DNS funciona e todo o demais se filtra, a túa regra é máis ampla que a de arriba.

Se as buscas seguen fallando despois de que a marca estea no seu sitio, resiste o impulso de ampliar a orixe. Comproba cara a onde reenvía dnsmasq, se o resolutor do convidado apunta a 192.168.122.1 ou a un enderezo público que alguén escribiu, e se a consulta chega sequera ao anfitrión. Marcar admite o paquete e nada máis, así que un mal ascendente ou unha rede virtual rota seguen rotos por moitas regras que engadas.

Artigos relacionados