OpenVPN iroute fronte á ruta do núcleo: cal falta?

Un paquete para 10.77.20.0/24 toma dúas decisións separadas nun servidor OpenVPN: o sistema operativo debe entregalo á interface VPN, e OpenVPN debe saber que cliente conectado posúe ese prefixo. Unha ruta do núcleo ausente descártao antes do túnel, e unha ruta do par ausente descártao despois. Os dous fallos vense idénticos desde a LAN remota, e diagnosticar cal ten require un comando en cada lado.

Na ruta de datos clásica en espazo de usuario, a ruta do núcleo leva o paquete ao proceso do túnel e iroute di a ese proceso que par debe recibilo. Ningunha substitúe a outra, e unha configuración que só leve unha delas parecerá razoable ata o primeiro ping.

Dúas decisións, non unha ruta

Imagine unha ligazón entre sedes onde 10.77.20.0/24 está detrás dun só cliente. A ruta do núcleo do servidor, por exemplo ip route add 10.77.20.0/24 dev tun0, envía os paquetes coincidentes ao dispositivo do túnel. Despois OpenVPN consulta a súa propia táboa interna, construída a partir das entradas iroute do directorio de configuración do cliente, para decidir que conexión de par os recibe. Sen a ruta do núcleo o paquete nunca chega ao proceso, e sen a ruta do par chega ao proceso e non vai a ningures.

Esa división esquécese con facilidade, porque unha soa liña de ruta nun perfil de cliente pode parecer que fai ambos traballos. Non os fai: empurrar unha ruta di aos clientes que enviar polo túnel, mentres que iroute di ao servidor quen posúe un rango de enderezos detrás dun cliente. Viven en ficheiros distintos, léenos lados distintos e fallan en direccións opostas.

Onde vai iroute e que di

A entrada vai nun ficheiro por cliente nomeado segundo o common_name do cliente, dentro de client-config-dir, como iroute 10.77.20.0/24. A coincidencia do nome do ficheiro non é cosmética: OpenVPN busca a identidade autenticada e le o ficheiro con exactamente ese nome, así que un ficheiro chamado site-a só ten efecto para un cliente cuxo nome común sexa site-a. Engada ccd-exclusive se os clientes sen ese ficheiro deben rexeitarse de plano, que é a configuración correcta cando cada cliente é unha pasarela de sede. Manteña un ficheiro por pasarela e nómbreo segundo o suxeito do certificado que realmente emite.

Probe a entrada desde o servidor antes de culpar a LAN remota. O ficheiro de estado lista os clientes conectados cos seus nomes comúns, e un servidor que se executa con --verb 4 rexistra a instalación de iroute cando o par se conecta. Se non aparece nada ao conectar, o ficheiro está no directorio equivocado ou nomea a identidade equivocada.

A trampa: ficheiro presente, identidade equivocada

Un iroute de aspecto correcto ligado ao par equivocado perde máis tempo que un ficheiro ausente, porque todo no disco parece correcto. O cambio de nome de certificados, os nomes comúns duplicados e username-as-common-name cambiando a identidade efectiva prodúceo todo. Comprobe que identidade autenticou o servidor en lugar da que agardaba: a saída de estado é autoritativa, mentres que o nome do ficheiro só é unha clave de busca.

Unha ruta tamén pode sobrevivir ao seu propietario. As rutas estáticas e as entradas iroute describen un prefixo, non unha garantía de dispoñibilidade, así que o tráfico pode seguir encamiñándose cara a un par que agora mesmo está desconectado.

Complete o camiño máis alá do par

A propiedade do par é a metade do camiño, non o final. O cliente debe reenviar paquetes do túnel á súa LAN, o que significa reenvío IP activado nese equipo e unha regra de devasa que permita o tránsito. Os equipos da LAN remota necesitan un camiño de volta para o enderezo do túnel: ou unha ruta que apunte de novo á pasarela, ou un deseño de NAT deliberado no lado do cliente. Confirme o axuste de reenvío no cliente con sysctl net.ipv4.ip_forward en lugar de supoñer un valor por defecto da distribución.

Se outros clientes VPN deben chegar a esa subrede, o arranxo volve medrar: o servidor necesita client-to-client, e eses clientes deben encamiñar o prefixo polo túnel. Nada diso se deduce da propia táboa de rutas do servidor.

Verifique un destino desde unha fonte real en lugar de desde o propio servidor. Un ping desde un equipo LAN non relacionado ata un equipo detrás do cliente exercita o camiño de volta, a regra de reenvío e a propiedade do par nun só movemento, mentres que un handshake correcto só demostra identidade. Logo desconecte o par propietario e anote que fai a ruta, porque esa resposta é o seu modo de fallo.