Puerto de origen del cliente frente al listener del servidor en un flujo VPN
Compare los dos números de puerto en un túnel: el listener fijo del servidor y el origen efímero del cliente, y cómo la traducción del router queda entre ambos.
En una misma conversación aparecen dos números y ninguno de los dos está mal. El registro del servidor muestra el listener que ofrece el servicio, el portátil muestra el socket que envió el datagrama, y un router intermedio puede reescribir el segundo a la salida. Comparar los extremos de la conversación es más útil que comparar los dígitos. La comparación de abajo mantiene separados el listener, el socket del cliente y el origen traducido, porque responden a preguntas distintas.
Dos números que describen extremos opuestos
El puerto configurado del servidor es el destino al que marca el cliente. Lo fija la política, aparece en el perfil y tiene que estar abierto en el lado del servidor. El puerto de origen del cliente se elige localmente, normalmente del rango efímero, y existe para que la respuesta tenga dónde aterrizar. Puede cambiar en cada reconexión, y nada del diseño depende de que sea estable.
Un router intermedio puede reescribir ese origen en su propia asignación 'NAT'. Por eso el número que se observa en el servidor a menudo no tiene relación con el que eligió el portátil.
Dónde cambia el número de origen a la salida
Tome un ejemplo inventado de IPv4: un cliente detrás de un router que traduce, un servidor con un solo listener 'UDP' y un único datagrama que cruza ambos. La tabla nombra cada extremo y qué le ocurre, en lugar de reproducir el paquete en tres puntos de observación.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
El destino es constante en cada fila, y solo cambia la identidad del origen. Requisitos de UDP NAT distinguen una dirección y un puerto internos de la asignación externa, que es exactamente la diferencia entre la segunda y la tercera fila. Un router puede conservar el puerto de origen del cliente o elegir otro; conservarlo no es algo que una aplicación deba suponer.
Lea los tres extremos en los propios hosts
Los listados de abajo vienen de tres máquinas distintas y, juntos, muestran toda la conversación. Ejecute el primero en el servidor, el segundo en el cliente y el tercero donde exista la asignación. Una sola línea de registro nunca muestra los tres.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194El primer listado demuestra que el servidor está ligado al puerto del servicio y muestra qué proceso lo posee. El segundo muestra el socket local del cliente y el destino al que marcó. El tercero muestra la asignación que creó el router, y es el único lugar donde aparece el origen traducido. Léalos en ese orden y los dos números dejan de parecer contradictorios.
Qué cambia una reconexión y qué no
Algunos routers conservan el puerto de origen del cliente cuando está libre, y otros asignan uno distinto cada vez. Ambos comportamientos son normales, y una aplicación que exija el primero se romperá con el segundo. Un cambio de asignación tras una reconexión o un cambio de red no es un fallo del servidor: el cliente abre un socket nuevo, el router asigna lo que tiene y el servidor ve un origen nuevo en el mismo listener. Lo que sería un fallo es esperar que el servidor acepte tráfico dirigido a un puerto de cliente arbitrario.
Los clientes OpenVPN de la comunidad obtienen este comportamiento mediante nobind, que deja que el sistema operativo elija el puerto local; el puerto remoto sigue viniendo del perfil. Enlazarlo explícitamente es una decisión deliberada, no un requisito del protocolo. El servidor sigue ofreciendo un extremo mientras los clientes eligen sus propias identidades locales.
Etiquete las capas por separado en el registro
Dentro del túnel hay una segunda conversación con puertos propios. Una petición HTTPS transportada por el túnel tiene destino TCP 443, mientras que la conexión cifrada exterior usa UDP 1194, así que cambiar el puerto de origen exterior no cambia nada del servicio interior.
Incluso en la capa exterior, el protocolo importa. UDP 1194 y TCP 1194 son extremos distintos, y un listener 'TCP' nunca recibirá un datagrama UDP porque el número coincida. Al documentar un despliegue, etiquete el listener del servidor, el socket del cliente y el origen traducido como tres cosas distintas, y añada el transporte a cada una.
Después deje que la política siga los roles. El servidor abre el transporte previsto en su listener y sigue autenticando al par; el cortafuegos del cliente admite las respuestas a su propio intercambio saliente sin publicar un servicio entrante. Un filtro sin estado necesita la dirección de retorno escrita explícitamente, y esa es la razón práctica por la que la distinción importa más allá de los diagramas ordenados.