Clientes OpenVPN em bridge sem internet? Verifique a regra NAT

O servidor em bridge está no ar, a regra masquerade existe, e o navegador no cliente continua girando. Tudo parece que deveria funcionar, e é por isso que a primeira hora vai para verificar o túnel e as credenciais. Então você lê o contador da regra NAT e encontra um zero que não se moveu. Uma regra que nunca contou um pacote nunca correspondeu a nenhum, e num servidor em bridge o motivo é estrutural: o tráfego do cliente sai pelo dispositivo tap virtual, enquanto a regra nomeia a placa física que você copiou de um guia antigo.

O contador é a evidência, não a entrada da tabela

Regras que existem e regras que correspondem são coisas diferentes, e o contador é o que as separa. Liste a tabela NAT com contadores detalhados e leia os números ao lado de cada regra antes de mudar qualquer coisa. Um contador parado em zero enquanto o tráfego flui significa que a regra foi ignorada, por mais sensatos que os endereços pareçam. Um contador que sobe enquanto a conexão ainda falha manda você para outro lugar: o encaminhamento, o caminho de volta ou o outro extremo.

iptables -t nat -L POSTROUTING -v -n

Leia primeiro o contador ao lado da correspondência de interface. Se o intervalo de origem estiver certo e o lado de saída estiver errado, a correção é uma palavra na regra, não uma regra completamente nova.

Encontre o nome que o kernel realmente registra

Identifique o nome do dispositivo de túnel antes de escrever a regra, usando a lista de interfaces em vez da memória. Numa configuração OpenVPN em bridge o dispositivo costuma ser uma interface tap criada pelo servidor, e o nome dela faz parte da sua configuração local, não de uma constante universal. Confirme que ela existe enquanto o túnel está ativo, porque um dispositivo que só aparece depois que um cliente se conecta fará um teste anterior parecer um problema de regra.

ip -brief link

Anote o nome. Todo comando posterior neste diagnóstico se refere a ele, e um erro de digitação aqui produz exatamente o mesmo contador zero do erro original.

Reescreva a regra para o dispositivo de túnel

Aponte a regra para o dispositivo de túnel e mantenha o intervalo de clientes como condição de correspondência, para que ela cubra o tráfego do túnel e deixe as próprias conexões do host em paz. Substitua pelo seu próprio intervalo e nome de dispositivo, porque ambos abaixo são exemplos e nenhum é portátil entre instalações.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

Depois verifique as outras duas condições que o mesmo sintoma esconde. Verifique se o encaminhamento está habilitado e, se não estiver, habilite-o na configuração da própria distribuição, não com um echo que desaparece após reiniciar. Leia também os contadores da cadeia forward e, se ela descartar o tráfego do túnel, permita aquela interface especificamente e deixe a política da cadeia intacta.

Ler a cadeia forward com contadores leva um comando e elimina metade das possibilidades restantes antes de você tocar em outra regra.

Por que a placa física nunca corresponde

Uma bridge é um switch de software montado a partir do dispositivo tap e de uma interface física. O quadro do cliente entra nesse switch e sai em direção à rede física como membro da bridge, e não como um pacote na placa. O kernel, portanto, atribui o pacote à bridge e à sua porta, e é por isso que a placa que você imaginava nunca aparece na correspondência. Nada está quebrado na interface física; ela simplesmente não é o dispositivo ao qual o kernel atribui aquele pacote.

O problema seguinte que as pessoas encontram vem da mesma estrutura: a filtragem de quadros numa bridge é um recurso separado da filtragem IP. Se o requisito for restrição em nível de quadro, ela pertence à filtragem da bridge, não a uma regra da tabela IP.

Prove de ponta a ponta e depois torne permanente

Suba um único cliente e faça ping em algo na LAN do servidor; esse caminho exercita o encaminhamento sem nenhuma tradução. Depois peça algo público para que a regra masquerade precise ser usada, e leia o contador mais uma vez: ele deve se mover para este teste e não para o anterior. Uma captura feita no dispositivo de túnel mostra tanto onde o quadro aparece quanto qual endereço ele carrega.

Último passo: coloque as regras que funcionam na configuração que uma reinicialização lê, e anote o nome do dispositivo que a bridge deste host realmente usa. Tudo o que for digitado à mão desaparece após reiniciar, e a mesma falha volta sem nada que a explique.

Se o contador ainda não se mover depois da reescrita, compare o intervalo de origem na regra com o endereço que o cliente realmente recebeu, porque um servidor em bridge pode distribuir endereços de um intervalo que você não pretendia.