Por qué solo se conecta un cliente VPN detrás del mismo router
El segundo portátil agota el tiempo mientras el primero funciona. Compare el registro del servidor, el comportamiento de paso del router y si ambos equipos comparten una identidad.
Dos portátiles están en la misma red doméstica, y la VPN de la oficina acepta exactamente uno de ellos. El segundo o agota el tiempo de espera o espera a que el primero se desconecte, y nadie tocó ningún ajuste del cliente entre los dos intentos. Las credenciales son las mismas que funcionaban hace un minuto, y esa es la pista de que la autenticación no es el fallo. Tres mecanismos producen este patrón, y el propio registro del servidor dice a cuál se enfrenta.
Lea el registro de la puerta de enlace antes de tocar un cliente
El registro del servidor de ambos intentos responde la primera pregunta, y lo hace de una de tres maneras. Si el segundo intento nunca aparece en ese registro, el paquete nunca llegó al escucha, y el problema es del router doméstico o del camino del proveedor. Si el registro anota un intento y lo rechaza, el túnel llegó, así que la cuestión es de identidad, de licencia o de límite de sesiones, no algo en el cable. Si el registro anota una sesión correcta mientras el cliente sigue informando de un fallo, mire el camino de vuelta o si se está dando la misma dirección de túnel a dos clientes.
Un punto de acceso del móvil separa esas familias a bajo coste: ejecute el segundo cliente por datos móviles mientras el primero sigue conectado. El éxito allí señala a la red doméstica, y el mismo fallo allí señala a la puerta de enlace, lo que deja inocente al router. Ningún resultado es concluyente por sí solo, pero cada uno elimina la mitad del espacio de búsqueda en un solo intento.
Anote el resultado antes de cambiar nada, porque las tres salidas del registro llevan a tres reparaciones sin relación. Una nota que nombre cuál de las tres vio vale más que una captura de pantalla de un error del cliente.
Qué hace el router con GRE y NAT-T
PPTP es el culpable clásico: el canal de control es TCP 1723 mientras que el camino de datos es GRE, el protocolo IP 47. Muchos routers domésticos incluyen un ayudante PPTP que sigue una sola conexión de control, así que un segundo cliente detrás del mismo NAT abre su canal de control y luego no recibe ningún camino de datos. Reenviar un puerto TCP con el número 47 no hace nada por GRE, porque GRE es un número de protocolo y no un puerto.
L2TP sobre IPsec se comporta distinto por diseño: IKE usa UDP 500, el tránsito NAT traslada la carga protegida a UDP 4500, y la encapsulación existe justamente para que varios clientes detrás de una dirección puedan llegar a la misma puerta de enlace. Ese diseño no impide que una puerta de enlace o un dispositivo intermedio imponga un límite de sesiones por dirección, y desde el sofá los dos fallos parecen idénticos. El protocolo nativo de SoftEther tiene la misma clase de problema: un router sin paso funcionante admite al primer cliente de la LAN y descarta al segundo. Pruebe el ALG o el interruptor de paso del router en las dos posiciones, porque un ayudante escrito para un cliente antiguo puede corromper paquetes que envía uno actual.
nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre
Límites de identidad que parecen límites de transporte
El router no es el único sospechoso, y el registro lo distingue de la alternativa. Cuando un servidor OpenVPN fija un nombre común a una dirección de túnel, ambos equipos reciben esa dirección, y sin duplicate-cn la sesión más nueva expulsa a la más antigua. Activar esa opción deja a ambos conectados pero los deja con una identidad, un certificado y una decisión de revocación, lo que es peor de lo que parece. El segundo equipo ya nunca podrá revocarse solo, así que un interruptor de comodidad retira en silencio un control que puede necesitar más adelante.
Lea el diario del servidor y su archivo de estado juntos, porque uno muestra la decisión de autenticación y el otro muestra quién está conectado ahora. Dos entradas que comparten un nombre común y una dirección virtual confirman una colisión de identidad y no un límite del router. Las puertas de enlace comerciales añaden límites propios, como un plan que permite una sola sesión simultánea, un recuento de licencias o una regla que permite una sesión por dirección pública, y ningún ajuste del router cambia nada de eso.
sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status
Ajuste la reparación a la entrada del registro
Un rechazo en el registro exige credenciales separadas por equipo, un límite más alto de quien gestiona el servicio, o un segundo punto final de puerta de enlace para una máquina. Si ningún segundo intento llega jamás al servidor, la reparación duradera es un router que reenvía el protocolo y sostiene más de una sesión, o un transporte que el router lleva bien, como un único flujo TCP o UDP. Elegir entre eso es una decisión sobre la vida del hardware, no sobre los ajustes del cliente.
No copie el perfil de un equipo que funciona a la segunda máquina y dé el asunto por terminado. Eso convierte un problema de conexión en un problema de control de acceso, porque un portátil perdido ya no se distingue de la copia que sigue en uso. También oculta el fallo original, que vuelve en el momento en que aparece un tercer equipo.
Verificar dos sesiones activas
Conecte ambos equipos a la vez, ejecute la aplicación prevista en cada uno, después reconecte uno de ellos y repita. Un segundo icono que aparece un instante no demuestra nada sobre el tráfico, y una sesión que cae a los diez minutos es otro fallo con otro responsable. Compare lo que el servidor informa al final con lo que vieron los usuarios, porque esos dos relatos a menudo no coinciden.
Si ambas sesiones sobreviven y llevan tráfico, la solución se sostiene y la nota que escribió al principio se convierte en el registro de lo que iba mal. Si solo sobrevive una, vuelva al primer paso y compruebe cuál de las tres salidas del registro tiene ahora, porque la respuesta puede haber cambiado. Los ayudantes del router pueden ocultar un problema que reaparece en otra red, mientras que un límite por dirección sigue al usuario y no al equipo. Probar desde una segunda red es la forma más barata de averiguar cuál de esas cosas ha arreglado de verdad.