Falta el pas de PPTP: corregeix l’error 807 del Windows VPN

Reenviar el TCP 1723 sovint obre la primera part de PPTP i deixa la resta trencada, així que el Windows encara retorna l’error 807 en l’intent. El següent impuls és afegir una regla per al port 47, i aquest és justament el pas que malbarata una tarda: GRE és un número de protocol dins la capçalera IP, no un port que una taula de reenviament pugui encaixar. Fins que l’encaminador deixi passar el protocol 47 i el lligui a la mateixa trucada, el túnel no pot arrencar. Les seccions de sota separen els dos canals i després els proven un a un.

Una taula de ports no té cap fila per a un número de protocol

PPTP fa servir dues converses que fallen de maneres diferents. La que va pel TCP 1723 inicia la trucada, passa la informació d’enllaç i la tanca quan l’usuari es desconnecta. El costat de les dades funciona dins de GRE, que la capçalera IP etiqueta amb el número de protocol 47, i dins d’aquest túnel PPP negocia l’enllaç mentre MS-CHAPv2 comprova les credencials.

Com que GRE no porta cap capçalera de transport, no exposa cap port, de manera que una regla escrita per a ports no té res a encaixar. Un encaminador que reenvia el 1723 crea una assignació per a aquesta sessió TCP i s’atura aquí. El firmware que gestiona la segona meitat anomena la funció pas de PPTP o PPTP ALG, i alguns firmwares no ofereixen cap de les dues coses i no esmenten mai el buit. L’etiqueta de la casella importa menys que si el protocol 47 es reconeix o no.

Què informa el Windows quan mor el camí de dades

L’error 807 diu que la connexió no s’ha pogut completar, cosa que en la pràctica vol dir que la trucada ha arribat al servidor i que el canal de dades no s’ha aixecat. És un veredicte sobre el transport, no un veredicte sobre el compte. L’error 691 és el que apunta a les credencials o a un desajust del protocol d’autenticació, així que us envia a un altre lloc ben diferent.

Treballa el transport abans de tocar la contrasenya. Canviar les credencials per perseguir el 807 deixa la falla real al seu lloc i fa que el proper intent sigui més difícil de llegir.

Per què un segon client trenca un túnel que funciona

Sense ports que els distingeixin, un dispositiu NAT no pot separar dos clients PPTP com separa dues sessions HTTPS. Per això molts dispositius de consum permeten una sola trucada PPTP i la segueixen per adreça d’origen. Un portàtil que funcionava sol deixa de completar quan un segon equip marca, i des del costat del client la falla sembla aleatòria. Aquest patró pertany al firmware, i cap canvi de perfil l’alterarà.

Mira la taula de connexions mentre els dos clients marquen. Si només el primer amfitrió té mai una assignació, l’encaminador ha arribat al límit del que admet i cap ajust del client el mourà.

Demostra quina meitat falla

Confirma que el TCP 1723 arriba abans de canviar res a l’encaminador, perquè aquesta resposta decideix quina meitat estàs provant. Executa aquestes ordres des del client Windows contra el teu propi nom de servidor. La primera imprimeix si el port ha respost, i la segona marca sense diàleg, cosa que fa comparables els intents repetits.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Un resultat cert a la prova del port vol dir que el canal de control és obert i que GRE és el sospitós restant. Un resultat fals vol dir que l’encaminament, un filtre o el reenviament estan trencats, i cap canvi de GRE ho salvarà. El costat de dades s’ha de vigilar allà on es pot veure, al servidor o a l’encaminador.

tcpdump -ni any proto 47

L’equivalent a Wireshark és el filtre de visualització ip proto 47, que és més fàcil de passar a algú que no està còmode amb una línia d’ordres. Un GRE que arriba sense res a la resposta vol dir que cal arreglar el camí de tornada.

Què arregla realment l’error

On l’encaminador exposa l’ajust, activa el pas de PPTP o permet explícitament el protocol 47 en un firmware que accepti regles. A RouterOS la regla de reenviament encaixa directament amb el protocol, cosa que un reenviament basat en ports mai no podria fer. El firmware de consum sol amagar la mateixa decisió darrere d’una casella, de vegades a la configuració de seguretat i no al reenviament de ports. Si no existeix cap control així, res al client ho compensarà.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

Substituir PPTP és l’altra opció i sovint la més barata. Un encaminador que acaba la VPN ell mateix evita el doble NAT per als clients entrants, i un protocol que un NAT basat en ports ja gestiona no necessita cap pas: OpenVPN sobre UDP, SSTP sobre TCP 443 o L2TP/IPsec amb NAT-T que embolcalla ESP dins d’UDP 4500. PPTP també depèn de MS-CHAPv2, les debilitats documentades del qual el fan una mala tria per a un desplegament nou fins i tot després que l’error desaparegui.

Anota quina regla ha marcat la diferència, perquè el mateix lloc trobarà el mateix límit quan el segon usuari demani accés. Una correcció a nivell de protocol pertany a les notes de xarxa, on mirarà el proper enginyer.