Dos direcciones de servicio en un cliente OpenVPN: iroute y lo

La aplicación responde en su dirección de túnel, y la dirección que documentó para ella no lleva a ninguna parte. Nada en el registro de OpenVPN se queja, el par se muestra conectado y el concentrador lista exactamente un cliente. El hueco es que una segunda dirección en un cliente son dos hechos separados: el host debe poseerla y el concentrador debe saber qué par la posee. Resuelva uno sin el otro y el tráfico o muere en el concentrador o llega sin ruta a casa.

El alias es local, la propiedad es remota

Una dirección de túnel se negocia, así que ambos extremos la aprenden durante el handshake. Una dirección de servicio adicional no se negocia en absoluto, por eso añadirla no cambia nada en el concentrador por sí sola. El cliente puede poseer la dirección de inmediato y el servidor seguirá enviando ese tráfico por su ruta predeterminada o lo descartará. Hay que crear dos registros, en dos lugares distintos.

En el cliente, la dirección pertenece al host, y loopback es el hogar natural para una identidad de servicio que nunca debería aparecer en un enlace físico. En el concentrador, la correspondencia de par a prefijo es una declaración separada que solo lee el servidor. Ninguno de los dos registros implica al otro.

Mantenga los dos rangos distintos también en sus notas. Las direcciones de un ejemplo son valores de documentación, y solaparlas con una LAN real es la forma más rápida de hacer que una configuración funcional parezca rota.

Añada la dirección en el cliente de forma persistente

Coloque la dirección de servicio en loopback con un prefijo de host, para que el host la trate como entrada local y no como una subred a la que llegar. ip address add 10.66.0.10/32 dev lo lo hace para una dirección, y repetir el comando para una segunda dirección modela dos servicios.

Ejecútelo como una prueba puntual y luego muévalo a lo que posee la configuración de red del host, porque una adición en tiempo de ejecución desaparece al reiniciar y los duplicados se acumulan entre reconexiones. Una unidad systemd ordenada después de la red es una opción, y un gestor de red de la distribución es otra. Elija la que elija, la dirección debe existir antes de que la aplicación se enlace, o el servicio aparece en el socket equivocado. Verifique con ip address show dev lo después de un reinicio y no después del comando manual.

El enlace es una decisión separada del direccionamiento. Una aplicación que escucha en todas las direcciones acepta tráfico en interfaces que nunca pretendió, así que apúntela a la dirección de servicio concreta. Entonces la política de entrada local tiene algo preciso con lo que coincidir.

Reclámela en el archivo CCD que el concentrador lee de verdad

En el servidor, la declaración de propiedad va en el archivo por cliente seleccionado por el nombre común autenticado, dentro del directorio indicado por client-config-dir. La línea es iroute 10.66.0.10 255.255.255.255, una por dirección, y dice al servidor qué par debe recibir el tráfico de ese destino.

Dos detalles rompen esto en silencio. El nombre del archivo debe coincidir con el nombre que el servidor usa realmente, que cambia cuando username-as-common-name está en juego. Y iroute solo surte efecto en modo TUN con un directorio de configuración de clientes configurado, así que la misma línea no hace nada en un despliegue en puente. Añada líneas al archivo existente en lugar de reemplazarlo, ya que puede llevar una dirección fija u opciones push. La referencia de OpenVPN 2.6 documenta tanto el directorio como la directiva de propiedad.

El propio núcleo del concentrador también necesita una ruta a esos destinos para que el tráfico generado localmente entre en el proceso del túnel. route 10.66.0.10 255.255.255.255 en la configuración del servidor cubre el tráfico que origina el servidor, mientras que otros clientes necesitan push "route 10.66.0.10 255.255.255.255" para aprender el destino por sí mismos.

El enrutamiento y la autorización siguen separados. Una ruta empujada dice a un cliente dónde enviar paquetes y no concede nada; el servicio todavía tiene que aceptar al llamante en sus propios términos.

Compruebe la política de entrada y la ruta de respuesta

Un paquete dirigido al alias llega al host propietario como entrada local, así que la pregunta es si el cortafuegos local permite esa fuente y ese puerto. Permita el puerto de servicio concreto desde el rango de origen de la VPN en lugar de abrir toda la dirección.

Las respuestas necesitan una ruta de vuelta al llamante. Para un llamante dentro del grupo de túnel normal esa ruta ya existe, porque la lleva el dispositivo de túnel. Un llamante detrás de otra red enrutada necesita también la ruta de retorno de esa red, y aquí es donde las configuraciones asimétricas pierden paquetes.

Vigile un segundo oyente en el mismo puerto vinculado a una dirección distinta, porque el núcleo entrega al socket que coincida y los resultados parecen aleatorios. Compruébelo con ss -lntp y confirme que la dirección vinculada es el alias del servicio. El NAT de origen no es necesario aquí, y añadirlo oculta la identidad del llamante de la que dependen sus registros.

Pruebe direcciones y propiedad por separado

Pruebe en dos pasos. Primero confirme que el host propietario puede alcanzar el servicio en su alias desde sí mismo, lo que separa los problemas de enlace y cortafuegos del enrutamiento. Luego pruebe desde un llamante VPN real usando la autenticación de la propia aplicación. Cuando el primero pasa y el segundo falla, la pieza que falta está en el lado del concentrador.

Compruebe también los modos de fallo que sobreviven a una conexión: el alias sigue asignado cuando el túnel está caído, y el concentrador conserva su ruta cuando el par está ausente. Ningún objeto por sí solo demuestra que el servicio sea alcanzable, y por eso la prueba en dos pasos supera a un solo ping desde un portátil.