O cliente OpenVPN chega ao servidor pero non aos equipos da LAN: lista de comprobación

O cliente di conectado, o enderezo do túnel responde a un ping e nada na LAN da oficina responde. Vexo isto tras case cada actualización do cliente, e o primeiro instinto é abrir a devasa, que adoita ser o movemento equivocado: o túnel está ben e a rotura está nun dos tres saltos que o paquete debe cruzar. Percorra a ruta na orde na que a toma o paquete, primeiro a ruta do cliente, logo o reenvío do servidor, logo a viaxe de volta, e atopará o culpable da avaría nun par de minutos.

Paso un: observe a decisión de encamiñamento do cliente

Antes de tocar o servidor, demostre que o cliente envía o paquete ao túnel. Pregunte ao núcleo que interface usaría para un equipo LAN concreto, en lugar de ler toda a táboa:

ip route get 192.168.50.10

Se a resposta nomea o seu adaptador físico e a pasarela da oficina, ningún cambio no lado do servidor pode axudar. OpenVPN só reparte rutas cando o servidor as empuxa, así que busque push "route 192.168.50.0 255.255.255.0" na configuración do servidor e volva conectar o cliente despois. A maioría dos clientes aplican as rutas empuxadas ao conectar, non cando recarga o perfil.

En Windows a mesma pregunta ten outro comando. Find-NetRoute -RemoteIPAddress 192.168.50.10 imprime a interface e o seguinte salto que elixiría a pila, e route print -4 mostra se o prefixo empuxado existe sequera.

Paso dous: confirme que o servidor reenviará o paquete

Se a ruta do cliente é correcta, o paquete chega ao servidor e o servidor debe aceptar reenvialo. O interruptor do núcleo é a primeira porta, e sysctl net.ipv4.ip_forward debe devolver 1. Poñelo con echo 1 > /proc/sys/net/ipv4/ip_forward funciona ata o seguinte reinicio, e é exactamente por iso que a mesma queixa volve semanas despois.

Anóteo nun lugar que sobreviva a un reinicio:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

A segunda porta é a táboa de filtros. Un equipo con Docker instalado adoita levar unha política FORWARD de DROP, e o túnel herda esa decisión. iptables -L FORWARD -v -n mostra tanto a política como os contadores de paquetes; se a política é DROP, o reenvío necesita unha aceptación explícita para o sentido do túnel cara á LAN e outra para a resposta.

Paso tres: siga o paquete ata a LAN e busque a resposta

Vixíe ambos os lados do servidor á vez. Capture no túnel e na interface LAN, filtrado a un cliente e un equipo para que a saída siga sendo lexible:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

As peticións que aparecen en tun0 e de novo en eth0 cunha orixe 10.8.0.x, seguidas de silencio, significan que o paquete chegou e a resposta foi a outro sitio. O equipo LAN responde á súa pasarela predeterminada, esa pasarela non ten ruta para o grupo de VPN, e a resposta morre no router da LAN. Facer ping ao equipo LAN desde o servidor non demostra nada sobre este camiño, porque ese tráfico nunca cruza o túnel.

Paso catro: escolla entre tradución e unha ruta de volta

Dous arranxos pechan o burato, e a elección ten consecuencias máis alá de se o ping funciona. A tradución de orixe fai que o servidor sexa o remitente aparente:

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

Limite a regra ao grupo e á interface LAN, e logo fágaa permanente, ou a seguinte recarga da devasa eliminará o seu arranxo sen aviso. O custo é a identidade: cada cliente parece o servidor VPN nos rexistros da LAN e nas regras de acceso, e per-client policy becomes guesswork.

Unha ruta estática para 10.8.0.0/24 no router da LAN, apuntando ao servidor VPN, mantén visibles os enderezos dos clientes e é a mellor resposta a longo prazo cando ese router é seu. Moitos sitios executan ambas durante un tempo, NAT para o arranxo inmediato e a ruta unha vez escrita a política da devasa. Se o servidor é un par site-to-site en lugar dun grupo, o lado do servidor tamén necesita un iroute para a subrede remota, doutro xeito a ruta do par existe pero o tráfico dos clientes nunca se asocia con ela.

Paso cinco: verifique desde o cliente e anote que cambiou

Pechar o bucle desde o cliente, non desde o servidor. Conéctese a un servizo real no equipo LAN e logo confirme que os contadores de tradución se moveron con iptables -t nat -L POSTROUTING -v -n, porque unha regra con cero paquetes é unha regra que nunca coincidiu. conntrack -L -s 10.8.0.5 mostra o fluxo e o seu estado cando necesita probas de que o sentido de volta se rastrexa.

Deixe unha nota na configuración do servidor: que subrede, que interface, que regra e se o router da LAN leva unha ruta de volta. A próxima vez que unha actualización do cliente borre unha ruta empuxada, esa nota converte unha sesión de apagar lumes nun arranxo dunha liña.