Unha regra NAT que debía dar a un grupo de clientes VPN a súa propia dirección pública está en cero paquetes, mentres o mesmo grupo segue saíndo coa orixe equivocada. A regra normalmente non se equivoca coa dirección; equivócase coa interface. -o eth0:0 apunta a un dispositivo que non existe, porque eth0:0 é unha etiqueta asociada a unha dirección en eth0. Mirar os contadores é a forma máis rápida de confirmalo, e a corrección é menor do que suxire a investigación.

Comproba como chama o kernel ao dispositivo

Le as dúas vistas por separado antes de cambiar nada:

ip link show
ip address show dev eth0
ip route get 203.0.113.20

A listaxe de ligazóns mostra interfaces. A listaxe de direccións pode mostrar unha segunda dirección IPv4 que leva a etiqueta eth0:0, e o dispositivo desa dirección segue a ser eth0. O manual de direccións de iproute2 trata a etiqueta como un nome da dirección, non como unha segunda ligazón, e esa é a distinción sobre a que xira todo o problema.

A historia explica a confusión. A antiga ifconfig eth0:0 sintaxe realmente parecía unha interface nova, e os scripts desa época aínda se refiren a unha. Nun sistema actual, o alias é unha etiqueta sobre unha dirección, e nada no camiño de encamiñamento ou de netfilter o trata como un punto de saída aparte.

Comproba con que coincidiu realmente a regra

Le os contadores xunto coa listaxe de regras en lugar de tiralo da memoria:

iptables -t nat -L POSTROUTING -v -n --line-numbers

Unha regra cuxo contador de paquetes queda a cero mentres flúe tráfico coincidente non se está avaliando, e unha condición de interface de saída que nomea eth0:0 é unha causa habitual. O dispositivo de saída que escolleu a ruta é eth0, así que unha condición que busca outro nome nunca se cumpre, sexa cal sexa a dirección de orixe que escolleu o kernel.

Cambia a condición ao dispositivo real e deixa a etiqueta fóra. Se necesitas distinguir dous grupos de clientes que comparten ese dispositivo, distíngueos por prefixo de orixe, non por un nome de interface que non pode existir. Dúas regras con coincidencias -s que non se solapan son lexibles e comprobables; unha regra cun dispositivo ficticio non é nin unha cousa nin a outra. Ponlle a cada regra un comentario que nomee o grupo, porque dentro de seis meses o prefixo por si só non lle dirá a ninguén por que está aí.

Comproba a ruta que escolleu o dispositivo

O NAT de postrouting execútase despois de que a ruta xa escollese unha interface de saída, así que a interface da regra debe ser a que escolleu a ruta. Pregúntalle directamente ao kernel con ip route get para unha dirección de cliente representativa e le tanto o dispositivo como a orixe que informa.

Se a resposta nomea eth0, a parte de interface da regra está resolta. Se nomea un dispositivo de túnel, o paquete nunca chega á regra que estás a editar, e a busca pasa á táboa de encamiñamento e ás súas prioridades. Unha regra que nunca coincide porque o paquete saíu por outro lado vese igual na saída de contadores que unha regra cun dispositivo mal escrito. Confirma cal dos dous casos tes antes de editar nada, porque o segundo necesita un cambio de encamiñamento e non un cambio de texto.

Escolle a orixe traducida a propósito

Unha vez que o dispositivo é correcto, a dirección de orixe é unha decisión aparte. Isto é só un grupo IPv4 ilustrativo e unha dirección de exemplo:

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

Escribir unha dirección en --to-source non fai que ninguén a encamiñe de volta cara a ti. O provedor de subida ou o titular da dirección ten que entregar as respostas desa dirección a este host, e a dirección ten que ser unha que esteas autorizado a usar. Se non o é, a regra coincidirá e traducirá e as respostas seguirán indo a outro sitio.

Cambiar a dirección de orixe non é o mesmo que cambiar a ligazón de subida. Cando o requisito real é un camiño físico distinto, a política de encamiñamento ten que seleccionar primeiro ese camiño; SNAT reescribe despois a orixe no dispositivo que escollese a política. Engadir máis etiquetas a eth0 non achega nin a ruta nin a autorización.

Verifica cunha conexión que acabas de abrir

Abre unha conexión de cliente nova en lugar de reutilizar unha existente. O seguimento de conexións conserva a tradución que rexistrou cando comezou o fluxo, así que unha sesión antiga pode seguir usando a dirección de orixe anterior e facer que unha regra nova correcta pareza rota. Observa como sobe o contador e despois mira a orixe traducida no cable ou no extremo remoto.

Cando varios grupos comparten unha interface, dálle a cada un unha coincidencia de orixe explícita e a súa propia dirección de tradución, manténos na configuración xestionada da devasa e anota a orde na que se avalían. Despois rexistra o que verificaches: o dispositivo de ip route get, o contador que se moveu e a orixe que viu o lado remoto. Ese rexistro responde ao seguinte informe sen repetir a confusión da etiqueta.

Artigos relacionados