Por que non se pode acceder á subrede detrás dun cliente OpenVPN?

Os ping á dirección do túnel do servidor funcionan, a táboa de rutas do cliente semella correcta e a LAN detrás dese cliente segue sendo inaccesible. A táboa de enrutamento do cliente semella correcta, o servidor ten unha ruta que apunta ao túnel e os paquetes seguen desaparecendo. É o síntoma clásico dun túnel layer-3 que non sabe que un dos seus clientes tamén é unha pasarela.

Unha interface tun non ten seguinte salto por cliente. O kernel ve unha soa interface con moitos pares, así que a decisión de que cliente debe recibir un paquete para unha LAN remota ten que tomarse dentro do proceso OpenVPN. Esa decisión configúrase con iroute e, sen ela, o paquete non ten a onde ir.

O servidor enruta por cliente, non por interface

Cando o servidor necesita enviar un paquete á dirección do túnel dun cliente, a resposta é inequívoca: a dirección pertence á sesión dese cliente. Cando o destino é toda unha subrede detrás dese cliente, a dirección non pertence a ninguén que o servidor coñeza, e a ruta do kernel cara ao túnel só di "por esta interface", sen dicir que par.

OpenVPN resólveo cunha táboa de enrutamento interna que asigna un prefixo de destino a un cliente concreto. Esa táboa constrúese con entradas iroute, por iso unha ruta normal no host do servidor non abonda. A ruta do kernel leva o paquete á interface do túnel; a asignación interna decide que sesión o recibe. Por iso tamén a reparación nunca aparece na saída de rutas do kernel.

Se falta a asignación, o paquete chega ao servidor, coincide coa ruta do túnel e descártase porque ningún cliente reclama o destino. Nada rexistra un erro limpo, por iso o fallo parece un burato negro silencioso en lugar dun bucle de enrutamento.

Escribir a entrada iroute que nomea o cliente

iroute vive nun ficheiro de configuración específico do cliente, non na configuración principal do servidor. Apunte o servidor a un directorio coa opción client-config-dir, despois cree un ficheiro cuxo nome sexa o nome común do certificado do cliente e coloque o prefixo dentro.

Para unha sucursal cuxa LAN é 10.20.0.0/24 e cuxo nome común de certificado é branch-router, o ficheiro nesa ruta contén unha liña como iroute 10.20.0.0 255.255.255.0. A configuración principal só necesita a opción do directorio; o prefixo vive co cliente.

O nome común é a parte fráxil. Un certificado emitido con outro suxeito, ou un despregamento que autentica usuarios por nome de usuario mentres o ficheiro se nomea polo certificado, produce un ficheiro que nunca se le. Comprobe o nome que o servidor informa realmente para a sesión e considere a opción que fai fallar un cliente non coincidente en lugar de conectarse en silencio sen as súas rutas. Renomear o ficheiro para que coincida co certificado é unha corrección de cinco minutos que evita unha noite moi longa.

Un cliente pode posuír varios prefixos. Engada unha liña iroute por rede e manteña a lista xunto ao resto da configuración dese cliente para que a asignación siga sendo auditable.

Construír o camiño de retorno en ambos os sentidos

Levar os paquetes á LAN remota é a metade do traballo. O cliente tamén debe enviar o tráfico desa LAN ao túnel, o que normalmente se fai empurrando unha ruta ao cliente: unha liña como push "route 10.8.0.0 255.255.255.0" di a cada cliente como chegar á rede do lado do servidor. Para a sucursal, a ruta equivalente apunta ao túnel para todo o que deba acadar no lado do servidor.

O sentido de retorno necesita un propietario no lado remoto. Nese lado, alguén debe coñecer o camiño de volta: unha ruta estática no router da LAN que apunte o pool de VPN ao servidor, ou tradución de direccións no servidor antes de que o tráfico entre na LAN. A ruta estática mantén as direccións orixinais visibles nos rexistros e nas regras de acceso, pero require a colaboración do propietario da LAN; a tradución é autosuficiente pero oculta quen se conectou realmente.

O reenvío debe estar activado no host do servidor. Sen el, o kernel acepta o paquete do túnel e négase a pasalo á interface da LAN, o que desde o punto de vista do cliente parece idéntico a unha iroute ausente.

Comprobar a accesibilidade coas sondas correctas

Probe por capas en lugar de facer ping ao extremo remoto e adiviñar. Desde o servidor, comprobe que existe a asignación interna para o prefixo e que a ruta do kernel apunta ao túnel. Desde o cliente, confirme que a ruta empurrada está instalada e que o seu camiño predeterminado para a dirección da LAN é o túnel.

Despois observe os paquetes. Unha captura na interface do túnel mostra se o servidor transmite cara ao cliente, e unha captura na interface da LAN mostra se reenvía. Se a primeira mostra paquetes e a segunda non, o problema é o reenvío ou un filtro; se ningunha mostra nada, a busca fallou antes.

Dous servidores unidos por un túnel repiten a mesma regra en ambos os lados: cada un necesita unha iroute para o pool do outro, e cada un necesita a ruta e o reenvío que fan simétrico o camiño. Enrutamento e política son asuntos separados aquí. O enrutamento decide a onde pode ir un paquete, mentres que unha regra FORWARD decide se pode, así que un cliente con dúas liñas iroute acada ambos os prefixos salvo que un filtro diga o contrario.