Marcas de nftables e enrutamento VPN: que regra gaña realmente

Unha marca posta en nftables debería enviar unha clase de tráfico polo túnel, e o tráfico segue saíndo pola interface física. O conxunto de regras parece correcto de forma illada. O que adoita ocorrer é que outra cousa escribiu a mesma marca, ou que a regra de enrutamento coincide cunha máscara que o novo valor xa non satisfai.

Comprobación 1: lea a regra coa que coincide o núcleo

Comece pola regra de política e non pola devasa. O núcleo consulta as regras por orde de prioridade e a primeira coincidencia decide a táboa. Lea o valor de fwmark e a máscara da propia regra, e despois confirme que un paquete coa marca que puxo coincide realmente con ela. Unha regra que espera un valor completo de 32 bits non coincidirá cun paquete que só leva un bit.

Despois confirme que táboa selecciona esa regra e que contén a táboa. Unha regra que apunta a unha táboa baleira produce un fallo de busca, o que en moitos sistemas significa que o paquete cae á regra seguinte e sae pola interface física.

Dous comandos o resolven: a lista de regras e a busca de ruta para o destino nesa táboa.

Comprobación 2: marca de paquete ou marca de conexión

nftables pode pór unha marca no paquete e unha marca na entrada de seguimento de conexións, e son obxectos distintos. A marca de paquete vive durante a pasada de procesamento do paquete, mentres que a marca de conexión persiste para o fluxo e debe copiarse deliberadamente. Pór unha e esperar a outra é un arranxo a medias habitual.

Se a regra de enrutamento se basea na marca de paquete, restaurar a marca de conexión máis adiante na ruta non fai nada para esa decisión, porque a decisión xa se tomou.

Decida que obxecto posúe o sinal de enrutamento e despois pona no punto onde se toma a decisión de enrutamento.

Comprobación 3: quen máis escribe esa marca

As propias ferramentas de WireGuard marcan os seus paquetes UDP para que o transporte cifrado non se enrute de volta ao túnel ao que pertence. Se o seu conxunto de regras asigna un valor non relacionado ao mesmo campo, esa exclusión desaparece e o tráfico exterior do túnel tenta entrar en si mesmo. O síntoma é un túnel que se estabelece e despois deixa de pasar tráfico.

As marcas tamén as usan outras ferramentas de devasa, a rede de contedores e o enrutamento por políticas para outros fins, así que dous subsistemas escribindo todo o campo é un conflito aínda que cada un sexa correcto por separado.

Enumere os escritores antes de engadir outro.

Comprobación 4: a máscara decide que conserva

Unha marca é un campo de 32 bits, e as máscaras son a forma en que varios propietarios o comparten. Pór un valor con máscara conserva os bits que vostede non posúe; pór todo o campo destrúe os de todos os demais. Lea a máscara en cada regra que toque o campo, incluídas as que non escribiu.

Documente a asignación de bits xunto ao conxunto de regras.

Se non, a seguinte persoa reutilizará un valor que xa ten propietario, e un conflito aquí parece un erro de enrutamento cando en realidade é un erro de direccionamento. A documentación de nftables sobre metadatos de paquetes describe as propias operacións de marca.

Comprobación 5: verifique cun fluxo real, non cunha busca

Unha busca de ruta simple non leva marca, así que pode amosar un camiño distinto do paquete real. Xere o tráfico que lle interesa e observe os contadores, a entrada de seguimento de conexións e a interface pola que sae realmente. Probe tanto a clase incluída como a clase excluída, porque unha marca demasiado ampla rompe a exclusión mentres parece exitosa. Se a clase incluída funciona e a clase excluída tamén entra no túnel, a marca é demasiado ampla e non demasiado estreita.

Evite baleirar o estado de conexións para forzar unha actualización durante unha sesión activa, xa que os fluxos novos e existentes poden tomar camiños distintos lexitimamente.

Rexiste a marca, a máscara e a táboa nun só lugar, e a seguinte edición vólvese revisable.