PPTP delt tunnel fungerer ikke: reparer GRE-stien først

Se en PPTP-tilkobling komme opp, og det er lett å tro at den vanskelige delen er gjort: klienten autentiserer seg, en ppp0-adapter eller WAN Miniport dukker opp, og statusvinduet blir grønt. Deretter løper den første forespørselen til en intern vert ut i tid, og profilen får skylden. I praksis er det to uavhengige lag å rydde: den ytre transporten som bærer TCP 1723 og GRE, og den indre policyen som bestemmer hvilke destinasjoner som bruker PPP-grensesnittet. En grønn status beviser bare at det første laget forhandlet; om det andre sier den ingenting.

Følg klienten fra profil til kontrollsocket

Åpne klientloggen og finn punktet der den kontakter serveren. PPTP åpner først en TCP-tilkobling til port 1723 og forhandler tunnelparametere over den kanalen. Hvis dette trinnet feiler, betyr ingenting senere noe, og feilen nevner vanligvis serveradressen eller en tidsavbrudd.

Bekreft kontrolltilkoblingen på nettet før du rører noen rute. På klienten eller en speilport fanger du TCP 1723 for ett tilkoblingsforsøk:

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

En fullført håndtrykk og en etablert sesjon betyr at den ytre kontrollkanalen fungerer. Et SYN som aldri får SYN-ACK, peker på en brannmur, feil serveradresse eller en leverandør som filtrerer porten. Et håndtrykk etterfulgt av en umiddelbar nullstilling betyr ofte at serveren avviste legitimasjonen eller tunneltypen.

GRE er en andre protokoll, ikke en port

PPTP bærer PPP-nyttelasten inne i utvidet GRE, IP-protokoll 47, som ikke har noe portnummer en ruter kan spore. Derfor kan en regel som tillater TCP 1723 fortsatt la tunnelen være uten datasti. Stateful NAT-enheter må forstå anrops-ID-en inne i GRE for å mappe svar tilbake, og mange gjør det ikke. PPTP-spesifikasjonen holder kontrollkanalen og GRE-nyttelasten som separate deler, og testplanen din må gjøre det samme.

Se etter protokoll 47 i samme opptak, og sammenlign deretter det som går ut, med det som kommer tilbake:

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

Pakker som går ut uten svar, mens TCP 1723 holder seg sunt, er den klassiske signaturen på blokkert GRE. PPTP-passthrough på en forbrukerruter er en funksjon i akkurat den fastvaren, så et fungerende hotellnettverk beviser ingenting om det neste. Hvis ruteren ikke tilbyr passthrough og du ikke kan endre det, er problemet protokollvalget, ikke rutetabellen.

Bevis at tunnelen flytter én pakke

Når GRE strømmer, tildeler PPP-forhandlingen en adresse til klientgrensesnittet. Les tildelingen i stedet for å anta den:

ip -4 addr show ppp0

Ping peer-adressen som vises som destinasjon for punkt-til-punkt-forbindelsen. Et svar på dette trinnet beviser at den innkapslede stien fungerer ende til ende, og at serveren svarer inne i tunnelen. Hvis peeren svarer men interne verter ikke, er den ytre transporten i orden, og feilen har flyttet seg innover.

Gjør dette før du legger til noen delt rute. En ruteendring som gjøres mens transporten er ødelagt, skaper en andre variabel og skjuler den første.

Skriv den delte policyen, inkludert DNS

Delt ruting er en liste med beslutninger, ikke en avkrysningsboks. Hvert private prefiks som må krysse tunnelen trenger en rute gjennom PPP-grensesnittet, og hvert prefiks som må forbli lokalt må mangle i den. En rute til et applikasjonssubnett uten en samsvarende rute til dens private resolver er en vanlig måte å lage et avbrudd som ser ut som en ødelagt app.

Kontroller beslutningen kjernen tar for én adresse i hver kategori:

ip route get 10.20.5.10
ip route get 203.0.113.25

Den første skal nevne ppp0, den andre den vanlige gatewayen. Hvis begge nevner samme grensesnitt, er policyen ikke delt i det hele tatt. Legg DNS-serverens egen adresse til tunnellisten, ellers går navneoppslaget for interne verter ut gjennom den lokale resolveren og returnerer ingenting nyttig.

En repeterbar kontroll i fem trinn

Kjør lagene i rekkefølge og stopp ved det første som feiler: kontrollkanal, GRE-synlighet, PPP-peer-svar, delt rute for én intern adresse, og en applikasjonsforespørsel over tunnelen. Hvert trinn har sin egen kommando, så en feil kan tilskrives i stedet for å være mystisk.

En kompakt versjon for en Linux-klient ser slik ut:

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

På Windows gjelder samme rekkefølge med route print og adapterstatusen som vises i klienten. PPTP er en eldre protokoll, og hvis serveren tilbyr SSTP eller IKEv2, er det å flytte seg vanligvis en bedre bruk av tiden enn å finjustere en sti som avhenger av at protokoll 47 passerer hvert hopp. Kontroller sertifikatet og autentiseringskontrakten til erstatningen i stedet for å kopiere en gammel profil inn i en ny versjon.