Por que só se conecta un cliente VPN detrás do mesmo router

Dous portátiles están na mesma rede doméstica, e a VPN da oficina acepta exactamente un deles. O segundo ou esgota o tempo ou espera a que o primeiro se desconecte, e ninguén tocou ningún axuste do cliente entre os dous intentos. As credenciais son as mesmas que funcionaban hai un minuto, e esa é a pista de que a autenticación non é o fallo. Tres mecanismos producen este patrón, e o propio rexistro do servidor di a cal se enfronta.

Lea o rexistro da pasarela antes de tocar un cliente

O rexistro do servidor dos dous intentos responde a primeira pregunta, e faino dunha de tres maneiras. Se o segundo intento nunca aparece nese rexistro, o paquete nunca chegou ao escoitador, e o problema é do router doméstico ou do camiño do provedor. Se o rexistro anota un intento e rexéitao, o túnel chegou, así que a cuestión é de identidade, de licenza ou de límite de sesións, non algo no cable. Se o rexistro anota unha sesión correcta mentres o cliente aínda informa dun fallo, mire o camiño de volta ou se se está a dar o mesmo enderezo de túnel a dous clientes.

Un punto de acceso do móbil separa esas familias a baixo custo: execute o segundo cliente por datos móbiles mentres o primeiro segue conectado. O éxito alí sinala a rede doméstica, e o mesmo fallo alí sinala a pasarela, o que deixa inocente ao router. Ningún resultado é concluínte por si só, pero cada un elimina a metade do espazo de busca nun só intento.

Anote o resultado antes de cambiar nada, porque as tres saídas do rexistro levan a tres reparacións sen relación. Unha nota que nomee cal das tres viu vale máis que unha captura de pantalla dun erro do cliente.

Que fai o router con GRE e NAT-T

PPTP é o culpable clásico: a canle de control é TCP 1723 mentres que o camiño de datos é GRE, o protocolo IP 47. Moitos routers domésticos inclúen un axudante PPTP que segue unha soa conexión de control, así que un segundo cliente detrás do mesmo NAT abre a súa canle de control e despois non recibe ningún camiño de datos. Reenviar un porto TCP co número 47 non fai nada por GRE, porque GRE é un número de protocolo e non un porto.

L2TP sobre IPsec compórtase distinto por deseño: IKE usa UDP 500, o tránsito NAT traslada a carga protexida a UDP 4500, e a encapsulación existe xustamente para que varios clientes detrás dun enderezo poidan chegar á mesma pasarela. Ese deseño non impide que unha pasarela ou un dispositivo intermedio impoña un límite de sesións por enderezo, e desde o sofá os dous fallos parecen idénticos. O protocolo nativo de SoftEther ten a mesma clase de problema: un router sen paso funcionante admite o primeiro cliente da LAN e descarta o segundo. Probe o ALG ou o interruptor de paso do router nas dúas posicións, porque un axudante escrito para un cliente antigo pode corromper paquetes que envía un actual.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

Límites de identidade que parecen límites de transporte

O router non é o único sospeitoso, e o rexistro distíngueo da alternativa. Cando un servidor OpenVPN fixa un nome común a un enderezo de túnel, ambos os equipos reciben ese enderezo, e sen duplicate-cn a sesión máis nova expulsa a máis antiga. Activar esa opción deixa a ambos conectados pero déixaos cunha identidade, un certificado e unha decisión de revogación, o que é peor do que parece. O segundo equipo xa nunca poderá revogarse só, así que un interruptor de comodidade retira en silencio un control que pode necesitar máis adiante.

Lea o diario do servidor e o seu ficheiro de estado xuntos, porque un amosa a decisión de autenticación e o outro amosa quen está conectado agora. Dúas entradas que comparten un nome común e un enderezo virtual confirman unha colisión de identidade e non un límite do router. As pasarelas comerciais engaden límites propios, como un plan que permite unha soa sesión simultánea, un reconto de licenzas ou unha regra que permite unha sesión por enderezo público, e ningún axuste do router cambia nada diso.

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

Axuste a reparación á entrada do rexistro

Un rexeitamento no rexistro esixe credenciais separadas por equipo, un límite máis alto de quen xestiona o servizo, ou un segundo punto final de pasarela para unha máquina. Se ningún segundo intento chega xamais ao servidor, a reparación duradeira é un router que reenvía o protocolo e sostén máis dunha sesión, ou un transporte que o router leva ben, como un único fluxo TCP ou UDP. Escoller entre iso é unha decisión sobre a vida do hardware, non sobre os axustes do cliente.

Non copie o perfil dun equipo que funciona á segunda máquina e dea o asunto por terminado. Iso converte un problema de conexión nun problema de control de acceso, porque un portátil perdido xa non se distingue da copia que segue en uso. Tamén oculta o fallo orixinal, que volve no momento en que aparece un terceiro equipo.

Verificar dúas sesións activas

Conecte ambos os equipos á vez, execute a aplicación prevista en cada un, despois reconecte un deles e repita. Un segundo ícone que aparece un instante non demostra nada sobre o tráfico, e unha sesión que cae aos dez minutos é outro fallo con outro responsable. Compare o que o servidor informa ao final co que viron os usuarios, porque eses dous relatos a miúdo non coinciden.

Se ambas as sesións sobreviven e levan tráfico, a solución sostiña e a nota que escribiu ao principio convértese no rexistro do que ía mal. Se só sobrevive unha, volva ao primeiro paso e comprobe cal das tres saídas do rexistro ten agora, porque a resposta pode ter cambiado. Os axudantes do router poden ocultar un problema que reaparece noutra rede, mentres que un límite por enderezo segue o usuario e non o equipo. Probar desde unha segunda rede é a forma máis barata de saber cal desas cousas arranxou de verdade.