Tunelul divizat PPTP nu funcționează: repară mai întâi calea GRE

Urmărește o conexiune PPTP cum urcă și e ușor să crezi că partea grea s-a terminat: clientul se autentifică, apare un adaptor ppp0 sau WAN Miniport, iar fereastra de stare devine verde. Apoi prima cerere către un host intern expiră, iar profilul este învinuit. În practică sunt două straturi independente de curățat: transportul exterior care duce TCP 1723 și GRE, și politica interioară care decide ce destinații folosesc interfața PPP. O stare verde dovedește doar că primul strat a negociat; despre al doilea nu spune nimic.

Urmărește clientul de la profil până la soclul de control

Deschide jurnalul clientului și găsește punctul în care contactează serverul. PPTP deschide mai întâi o conexiune TCP către portul 1723 și negociază parametrii tunelului pe acel canal. Dacă acest pas eșuează, nimic ulterior nu mai contează, iar eroarea indică de obicei adresa serverului sau un timeout.

Confirmă conexiunea de control pe rețea înainte de a atinge vreo rută. Pe client sau pe un port oglindă, capturează TCP 1723 pentru o singură încercare de conectare:

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

Un handshake finalizat și o sesiune stabilită înseamnă că canalul de control exterior funcționează. Un SYN care nu primește niciodată SYN-ACK indică un firewall, o adresă de server greșită sau un furnizor care filtrează portul. Un handshake urmat de un reset imediat înseamnă adesea că serverul a respins acreditările sau tipul de tunel.

GRE este un al doilea protocol, nu un port

PPTP transportă încărcătura PPP în interiorul GRE extins, protocolul IP 47, care nu are un număr de port pe care un router să îl poată urmări. De aceea o regulă care permite TCP 1723 poate lăsa tunelul fără cale de date. Dispozitivele NAT cu stare trebuie să înțeleagă ID-ul apelului din GRE pentru a mapa răspunsurile, iar multe nu o fac. Specificația PPTP ține canalul de control și încărcătura GRE ca piese separate, iar planul tău de testare trebuie să facă la fel.

Urmărește protocolul 47 în aceeași captură, apoi compară ce iese cu ce se întoarce:

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

Pachetele care ies fără răspunsuri, în timp ce TCP 1723 rămâne sănătos, sunt semnătura clasică a GRE blocat. Passthrough-ul PPTP pe un router de consum este o funcție a acelui firmware anume, așa că o rețea de hotel care funcționează nu dovedește nimic despre următoarea. Dacă routerul nu oferă passthrough și nu îl poți schimba, problema este alegerea protocolului, nu tabela de rute.

Demonstrează că tunelul mută un pachet

Când GRE curge, negocierea PPP atribuie o adresă interfeței clientului. Citește atribuirea în loc să o presupui:

ip -4 addr show ppp0

Fă ping la adresa partenerului arătată ca destinație a legăturii punct la punct. Un răspuns în această etapă dovedește că calea încapsulată funcționează de la un capăt la altul și că serverul răspunde în interiorul tunelului. Dacă partenerul răspunde dar hosturile interne nu, transportul exterior este în regulă și defecțiunea s-a mutat spre interior.

Fă asta înainte de a adăuga orice rută divizată. O modificare de rută făcută cât timp transportul este stricat creează o a doua variabilă și o ascunde pe prima.

Scrie politica divizată, inclusiv DNS

Rutarea divizată este o listă de decizii, nu o casetă de bifare. Fiecare prefix privat care trebuie să traverseze tunelul are nevoie de o rută prin interfața PPP, iar fiecare prefix care trebuie să rămână local trebuie să lipsească din ea. O rută către o subrețea de aplicație fără ruta corespunzătoare către resolverul ei privat este o modalitate obișnuită de a crea o întrerupere care arată ca o aplicație stricată.

Verifică decizia pe care o ia kernelul pentru o adresă din fiecare categorie:

ip route get 10.20.5.10
ip route get 203.0.113.25

Prima trebuie să numească ppp0, a doua gateway-ul obișnuit. Dacă ambele numesc aceeași interfață, politica nu este deloc divizată. Adaugă adresa serverului DNS însuși la lista tunelată, altfel rezolvarea numelor pentru hosturile interne iese prin resolverul local și nu întoarce nimic util.

O verificare repetabilă în cinci pași

Rulează straturile în ordine și oprește-te la primul care eșuează: canal de control, vizibilitate GRE, răspunsul partenerului PPP, rută divizată pentru o adresă internă și o cerere de aplicație prin tunel. Fiecare pas are comanda lui, așa că o defecțiune este atribuibilă în loc să fie misterioasă.

O versiune compactă pentru un client Linux arată astfel:

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

Pe Windows se aplică aceeași ordine cu route print și starea adaptorului afișată în client. PPTP este un protocol vechi, iar dacă serverul oferă SSTP sau IKEv2, mutarea este de obicei o mai bună folosire a timpului decât reglarea unei căi care depinde de trecerea protocolului 47 la fiecare salt. Verifică certificatul și contractul de autentificare al înlocuitorului în loc să copiezi un profil vechi într-o versiune nouă.