¿Necesita cada peer de OpenVPN una línea remote? No exactamente
remote indica adónde va el primer paquete; no elige el papel de cliente, servidor o TLS. Lee la disposición antes de copiarla a ambos lados.
Se comparan dos configuraciones de peer una al lado de la otra, una tiene una línea remote y la otra no, y la conclusión es que una de ellas está rota. Esa inferencia es errónea con la suficiente frecuencia como para merecer un análisis. La directiva describe adónde debe enviarse el primer paquete. No selecciona si el proceso actúa como cliente que inicia o como puerta de enlace que espera, y no decide qué lado demuestra su identidad ante el otro.
Qué especifica realmente remote
Una entrada remote nombra un host, opcionalmente un puerto y un transporte, y opcionalmente varias de esas entradas que se prueban en orden.
Su ausencia tiene un significado definido y no indefinido: el proceso espera y no actúa sobre paquetes de una dirección a menos que ese peer se autentique. Por eso una puerta de enlace que atiende a usuarios itinerantes no tiene motivo para nombrar a ninguno de ellos de antemano.
Lee la entrada como una relación de direcciones. Si se confía en el extremo remoto lo responden los certificados y las opciones de verificación, no el hecho de que se haya escrito una dirección.
Tres disposiciones deciden la respuesta
Un cliente itinerante necesita un destino, porque debe iniciar y sin uno no sabe dónde está la puerta de enlace. Una puerta de enlace para varios clientes no necesita un destino por usuario, porque los clientes llegan y se autentican. Un enlace deliberado entre dos peers con extremos conocidos puede tener destino en un lado, en ambos o en ninguno, según qué lado inicie.
Pegar una dirección de cliente fija en una puerta de enlace general es el error que se deriva de ignorar esas categorías. Funciona para el único peer cuya dirección se registró y engaña a todos los demás.
Nada en la directiva convierte una configuración en un servidor para varios clientes, y nada en su presencia impide un papel de servidor. La referencia de OpenVPN 2.6 documenta los argumentos opcionales y el comportamiento sin remote por separado, lo que es una pista de hasta qué punto son independientes.
| Arrangement | Needs a destination |
|---|---|
| Roaming client | Yes, which gateway to contact |
| Multi-client gateway | No, peers authenticate on arrival |
| Two known peers | Depends on which side initiates |
Los papeles de transporte son otro eje
Con TCP, un lado espera y el otro establece la conexión. Son directivas separadas del destino, y mezclarlas produce una pareja en la que ambos esperan o ambos establecen la conexión.
También existe un papel de filtro de origen TCP, y por eso es incorrecta la afirmación tajante de que un servidor no puede contener nunca remote.
Con UDP no hay conexión que establecer, así que ambos extremos usan el transporte UDP correspondiente y la directiva solo dice hacia dónde apuntar. Los cambios de dirección de un peer autenticado se gestionan con un comportamiento dedicado y no añadiendo más entradas. Acertar con el transporte es una condición previa para que el destino signifique algo, y confundir ambos produce configuraciones que parecen plausibles y nunca completan un handshake.
Por qué un remote ausente no es una puerta abierta
Un proceso sin destino sigue rechazando el tráfico de peers que no se autentican, y esa es la parte que la gente pasa por alto cuando lee la línea ausente como un oyente abierto a cualquiera.
La autenticación y el destino son independientes, y la primera es la que importa para la confianza.
El error inverso es más peligroso. Una dirección de origen fija puede parecer un control de acceso porque es concreta y fácil de comprobar, pero no demuestra nada sobre quién está al otro lado. Conserva la verificación de certificados y las comprobaciones de identidad que vinculan un certificado con su papel. Sustituirlas por una coincidencia de direcciones cambia un control real por la apariencia de uno.
Anota qué asume la configuración
Para cada lado, registra tres cosas: cómo llega el primer paquete al peer, qué lado puede aceptar el transporte y qué verifica cada lado sobre el otro.
Esas suposiciones son el diseño. Las directivas solo son su escritura.
Si los dos archivos difieren, comprueba si expresan suposiciones distintas en lugar de suponer que uno está mal. Una pareja simétrica de archivos no es necesaria ni suficiente para un túnel funcional, y la asimetría suele ser la parte que hace funcionar una topología.