L’encaminament dividit de PPTP no funciona: arregla primer el camí GRE

Observeu com s’aixeca una connexió PPTP i és fàcil creure que la part difícil ja està feta: el client s’autentica, apareix un adaptador ppp0 o WAN Miniport i la finestra d’estat es torna verda. Llavors la primera petició a un host intern caduca i es culpa el perfil. A la pràctica hi ha dues capes independents per superar: el transport exterior que porta TCP 1723 i GRE, i la política interior que decideix quins destins utilitzen la interfície PPP. Un estat verd només demostra que la primera capa ha negociat; no diu res de la segona.

Seguiu el client des del perfil fins al sòcol de control

Obriu el registre del client i trobeu el punt on contacta amb el servidor. PPTP primer obre una connexió TCP al port 1723 i negocia els paràmetres del túnel per aquest canal. Si aquest pas falla, res posterior no importa, i l’error sol indicar l’adreça del servidor o un temps d’espera esgotat.

Confirmeu la connexió de control a la xarxa abans de tocar cap ruta. Al client o en un port mirall, captureu TCP 1723 per a un intent de connexió:

sudo tcpdump -ni any 'tcp port 1723' -c 20

Una negociació completada i una sessió establerta volen dir que el canal de control exterior funciona. Un SYN que mai no rep un SYN-ACK apunta a un tallafoc, a una adreça de servidor incorrecta o a un proveïdor que filtra el port. Una negociació seguida d’un reinici immediat sovint vol dir que el servidor ha rebutjat les credencials o el tipus de túnel.

GRE és un segon protocol, no un port

PPTP porta la càrrega PPP dins de GRE millorat, el protocol IP 47, que no té cap número de port que un encaminador pugui seguir. Per això una regla que permet TCP 1723 encara pot deixar el túnel sense camí de dades. Els dispositius NAT amb estat han d’entendre l’identificador de trucada dins de GRE per mapar les respostes, i molts no ho fan. L’especificació de PPTP manté el canal de control i la càrrega GRE com a peces separades, i el vostre pla de proves també ho ha de fer.

Vigileu el protocol 47 a la mateixa captura i després compareu què surt amb què torna:

sudo tcpdump -ni any 'proto gre' -c 20

Els paquets que surten sense resposta, mentre TCP 1723 es manté sa, són la signatura clàssica de GRE bloquejat. El pas de PPTP en un encaminador domèstic és una característica d’aquest microprogramari concret, així que una xarxa d’hotel que funciona no demostra res sobre la següent. Si l’encaminador no ofereix pas i no el podeu canviar, el problema és l’elecció de protocol, no la taula d’encaminament.

Demostreu que el túnel mou un paquet

Quan GRE flueix, la negociació PPP assigna una adreça a la interfície del client. Llegiu l’assignació en lloc de suposar-la:

ip -4 addr show ppp0

Feu ping a l’adreça de l’igual que es mostra com a destí de l’enllaç punt a punt. Una resposta en aquesta etapa demostra que el camí encapsulat funciona d’extrem a extrem i que el servidor respon dins del túnel. Si l’igual respon però els hosts interns no, el transport exterior està bé i la fallada s’ha mogut cap endins.

Feu-ho abans d’afegir qualsevol ruta dividida. Un canvi de ruta fet mentre el transport està trencat crea una segona variable i amaga la primera.

Escriviu la política dividida, DNS inclòs

L’encaminament dividit és una llista de decisions, no una casella de verificació. Cada prefix privat que ha de creuar el túnel necessita una ruta per la interfície PPP, i cada prefix que ha de quedar local ha d’estar absent d’ella. Una ruta per a una subxarxa d’aplicació sense una ruta corresponent al seu resolutor privat és una manera habitual de crear una caiguda que sembla una aplicació espatllada.

Comproveu la decisió que pren el nucli per a una adreça de cada categoria:

ip route get 10.20.5.10
ip route get 203.0.113.25

La primera ha de nomenar ppp0, la segona la passarel·la habitual. Si totes dues nomenen la mateixa interfície, la política no està dividida en absolut. Afegiu l’adreça del mateix servidor DNS a la llista tunnellitzada, si no la resolució de noms per als hosts interns surt pel resolutor local i no torna res d’útil.

Una comprovació repetible en cinc passos

Executeu les capes en ordre i atureu-vos a la primera que falli: canal de control, visibilitat de GRE, resposta de l’igual PPP, ruta dividida per a una adreça interna i una petició d’aplicació pel túnel. Cada pas té la seva ordre, així que una fallada és atribuïble en lloc de misteriosa.

Una versió compacta per a un client Linux és així:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

A Windows s’aplica el mateix ordre amb route print i l’estat de l’adaptador que mostra el client. PPTP és un protocol llegat, i si el servidor ofereix SSTP o IKEv2, moure’s sol ser un millor ús del temps que ajustar un camí que depèn que el protocol 47 passi per cada salt. Comproveu el certificat i el contracte d’autenticació del reemplaçament en lloc de copiar un perfil antic en una versió nova.