Os clientes OpenVPN con ponte non teñen internet? Comprobe a regra NAT

O servidor con ponte está activo, a regra masquerade está presente e o navegador do cliente segue xirando. Todo parece que debería funcionar, e por iso a primeira hora vaise en comprobar o túnel e as credenciais. Despois le o contador da regra NAT e atopa un cero que non se moveu. Unha regra que nunca contou un paquete nunca coincidiu con ningún, e nun servidor con ponte a razón é estrutural: o tráfico do cliente sae polo dispositivo virtual tap, mentres que a regra nomea a tarxeta física que copiou dunha guía máis antiga.

O contador é a proba, non a liña da táboa

As regras que existen e as regras que coinciden son cousas distintas, e o contador é o que as separa. Liste a táboa NAT con contadores detallados e lea os números xunto a cada regra antes de cambiar nada. Un contador parado en cero mentres o tráfico flúe significa que a regra se saltou, por razoables que parezan as súas direccións. Un contador que sobe mentres a conexión segue fallando mándao a outro sitio: o reenvío, o camiño de volta ou o extremo remoto.

iptables -t nat -L POSTROUTING -v -n

Lea primeiro o contador xunto á coincidencia de interface. Se o rango de orixe é correcto e o lado de saída é incorrecto, a corrección é unha palabra na regra e non unha regra completamente nova.

Atope o nome que o núcleo rexistra realmente

Identifique o dispositivo do túnel polo nome antes de escribir a regra, usando a lista de interfaces en lugar da memoria. Nunha instalación OpenVPN con ponte o dispositivo adoita ser unha interface tap creada polo servidor, e o seu nome forma parte da súa configuración local, non é unha constante universal. Confirme que existe mentres o túnel está activo, porque un dispositivo que só aparece despois de que un cliente se conecte fará que unha proba anterior pareza un problema de regra.

ip -brief link

Anote o nome. Cada comando posterior deste diagnóstico refírese a el, e unha errata aquí produce exactamente o mesmo contador nulo que o erro orixinal.

Reescriba a regra contra o dispositivo do túnel

Apunte a regra ao dispositivo do túnel e manteña o rango de clientes como condición de coincidencia, de modo que cubra o tráfico do túnel e deixe en paz as conexións propias do equipo. Substitua polo seu propio rango e nome de dispositivo, porque os dous exemplos de abaixo son exemplos e ningún é portable entre instalacións.

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

Despois comprobe as outras dúas condicións que agocha o mesmo síntoma. Comprobe se o reenvío está habilitado e, se non o está, habilíteo na configuración propia da distribución en vez de cun echo que desaparece ao reiniciar. Lea tamén os contadores da cadea forward e, se descarta o tráfico do túnel, permita esa interface en concreto e deixe a política da cadea intacta.

Ler a cadea forward con contadores custa un comando e descarta a metade das posibilidades restantes antes de tocar outra regra.

Por que a tarxeta física nunca coincide

Unha ponte é un conmutador de software composto polo dispositivo tap e unha interface física. A trama do cliente entra nese conmutador e sae cara á rede física como membro da ponte, non como un paquete na tarxeta. Por iso o núcleo atribúe o paquete á ponte e ao seu porto, e por iso a tarxeta que tiña en mente nunca aparece na coincidencia. A interface física non ten nada roto; simplemente non é o dispositivo ao que o núcleo atribúe ese paquete.

O seguinte problema co que a xente tropeza vén da mesma estrutura: o filtrado de tramas nunha ponte é un mecanismo aparte do filtrado IP. Se o requisito é unha restrición a nivel de trama, pertence ao filtrado da ponte, non a unha regra da táboa IP.

Demóstroo de principio a fin e despois faino permanente

Levante un só cliente e faga ping a algo na LAN do servidor; esa ruta exercita o reenvío sen ningunha tradución. Despois pida algo público para que a regra masquerade teña que usarse, e lea o contador unha vez máis: debería moverse para esta proba e non para a anterior. Unha captura tomada no dispositivo do túnel mostra á vez onde aparece a trama e que dirección leva.

Último paso: poña as regras que funcionan na configuración que le un reinicio e anote o nome do dispositivo que a ponte deste equipo usa realmente. Todo o escrito a man desaparece tras un reinicio, e o mesmo fallo volve sen nada que o explique.

Se o contador segue sen moverse tras reescribir a regra, compare o rango de orixe da regra coa dirección que o cliente recibiu realmente, porque un servidor con ponte pode repartir direccións dun rango que vostede non pretendía.