¿Debería su cliente OpenVPN usar nobind o un puerto fijo?

Dos perfiles que difieren en una sola línea se comportan de forma distinta en el momento en que un segundo cliente arranca en el mismo host. Uno lleva nobind y toma cualquier puerto local que le dé el núcleo; el otro reserva 1194, y la segunda instancia muere con una dirección ya en uso. Esa línea decide quién elige el puerto de origen, lo que a su vez decide si el perfil puede convivir con cualquier otra cosa en la máquina. Tres preguntas lo resuelven, y la primera responde a la mayoría de los perfiles antes de que llegue a las otras dos.

Qué omite realmente nobind

Por defecto el cliente enlaza un socket local antes de marcar, y el puerto local es 1194 salvo que el perfil diga lo contrario. nobind elimina esa reserva, así que la pila asigna un puerto no usado en el momento de la conexión. Es una excepción, no un valor por defecto, y un cliente sin la línea retiene 1194, que es exactamente por lo que choca una segunda instancia no fijada. La mayoría de los perfiles de cliente distribuidos llevan la directiva por ese motivo, y que un archivo de ejemplo haga algo no es lo mismo que el mecanismo lo haga por defecto.

Lo que no cambia es el lado lejano. El servidor sigue escuchando donde el perfil dice que escucha, y el puerto de destino en la configuración sigue siendo el puerto de destino. Un puerto de origen dinámico cambia la dirección de retorno de su propio socket y nada del del servidor.

Tampoco oculta nada. Su dirección pública es aquello a lo que la ruta la traduce, el paquete sigue cruzando la red local, y quien gestione esa red sigue viendo un flujo. nobind no es ni una función de privacidad ni una elusión de cortafuegos.

Tres condiciones que lo deciden

Una pregunta decide las otras dos, así que respóndala antes de editar nada. Si el par marca, las preguntas restantes solo afinan una decisión ya tomada. Si acepta conexiones entrantes, ningún ajuste del puerto local lo hace alcanzable.

¿Inicia este par la conexión? Si marca, un puerto de origen dinámico es inofensivo y normalmente preferible, porque la respuesta vuelve por el mismo flujo. Si espera conexiones entrantes, un puerto dinámico lo hace inalcanzable a menos que algo delante publique el puerto. Esa única respuesta separa cada perfil de cliente de cada perfil de servidor.

¿Filtra la ruta por el puerto de origen? Una regla estricta escrita para un puerto conocido obliga a un puerto local explícito, y el perfil debería registrar qué regla cumple. La mayoría de las redes filtran solo por destino, así que esta condición es más rara que la primera. Donde se aplica, anula la preferencia por un puerto dinámico.

¿Comparten varias instancias el host? Un solo puerto fijo no puede servir a dos de ellas, y una instancia reiniciada puede encontrar 1194 todavía en estado de cierre. Los puertos dinámicos eliminan ese conflicto sin cambiar nada más. Si no puede responder esto con confianza, asuma que sí y deje que el núcleo elija.

Dónde un puerto fijado es la respuesta correcta

Algunas redes filtran por el puerto de origen además de por el destino, así que un operador puede haber escrito una regla que solo deja pasar tráfico de un puerto conocido. Fijar el puerto local es entonces correcto, y el perfil debería llevar un comentario que nombre la regla que cumple. Fijarlo por simetría con el puerto del servidor no es un motivo, porque los dos números no tienen nada que ver entre sí. Si la fijación existe solo porque la tenía una plantilla, bórrela.

De lo contrario, un puerto fijado compra problemas: dos clientes en una máquina no pueden mantener ambos 1194, y el segundo falla con un error que apunta al puerto y no al perfil. Un contenedor que se reinicia rápido choca con el mismo muro. La reparación es la directiva que los perfiles distribuidos ya contenían.

Servidor y cliente no son simétricos

manual de OpenVPN 2.6 coloca nobind junto a lport, que es el argumento en una línea: una opción dice que elige el núcleo, la otra dice que elige usted. Un puerto local dinámico solo funciona para el par que marca, porque el lado que responde no puede conocer el puerto de antemano. Por eso copiar un perfil de cliente a un servidor produce un oyente al que nadie puede llegar.

En un host con varias interfaces de red, la dirección es una decisión separada del puerto. Enlazar una dirección local concreta y enlazar un puerto concreto son dos ajustes distintos, y un servidor con dos enlaces ascendentes normalmente fija ambos. Un cliente que fija ambos ha asumido la misma rigidez sin ningún beneficio.

El resumen trata de roles y no de seguridad: quien marca puede ser flexible con su propio origen, y quien responde no puede. Ninguna de las dos opciones cambia lo que el otro extremo aprende sobre su identidad. Por eso la directiva aparece en los ejemplos de cliente y casi nunca en los de servidor.

Verifique el puerto que eligió el núcleo

Tras conectar, lea el socket y no la configuración, porque la configuración declara la intención y el socket declara lo que ocurrió. Los hechos que merece la pena registrar son el puerto local, el extremo remoto y si algo sigue escuchando. En un host Linux los tres están a un comando de distancia.

ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn

Un cliente con nobind muestra un puerto local alto y el puerto remoto configurado, que es la forma esperada. Un servidor muestra un socket escuchando en su puerto configurado, y si ese socket falta, el perfil o no es un oyente o no pudo enlazar. Cuando existe un flujo pero no vuelven paquetes, compare el puerto de origen elegido con cualquier filtro de puertos de la ruta antes de editar el perfil. Cambie una cosa, reconecte y lea el socket de nuevo.