PPTP delt tunnel fungerer ikkje: reparer GRE-stien først
Delt tunnel i PPTP feilar av to ulike grunnar: GRE er blokkert, eller den indre ruta manglar. Test transporten først, deretter politikken.
Sjå ein PPTP-tilkopling kome opp, og det er lett å tru at den vanskelege delen er gjort: klienten autentiserer seg, ein ppp0-adapter eller WAN Miniport dukkar opp, og statusvindauget blir grønt. Deretter renn den første førespurnaden til ein intern vert ut i tid, og profilen får skulda. I praksis er det to uavhengige lag å rydde: den ytre transporten som ber TCP 1723 og GRE, og den indre politikken som avgjer kva destinasjonar som brukar PPP-grensesnittet. Ein grøn status beviser berre at det første laget forhandla; om det andre seier han ingenting.
Følg klienten frå profil til kontrollsocket
Opne klientloggen og finn punktet der han kontaktar serveren. PPTP opnar først ein TCP-tilkopling til port 1723 og forhandlar tunnelparametrar over den kanalen. Viss dette trinnet feilar, betyr ingenting seinare noko, og feilen nemner vanlegvis serveradressa eller eit tidsavbrot.
Stadfest kontrolltilkoplinga på nettet før du rører noka rute. På klienten eller ein spegelport fangar du TCP 1723 for eitt tilkoplingsforsøk:
sudo tcpdump -ni any 'tcp port 1723' -c 20
Eit fullført handtrykk og ein etablert sesjon betyr at den ytre kontrollkanalen fungerer. Eit SYN som aldri får SYN-ACK, peikar på ein brannmur, feil serveradresse eller ein leverandør som filtrerer porten. Eit handtrykk etterfølgt av ein umiddelbar nullstilling betyr ofte at serveren avviste legitimasjonen eller tunneltypen.
GRE er ein andre protokoll, ikkje ein port
PPTP ber PPP-nyttelasta inne i utvida GRE, IP-protokoll 47, som ikkje har noko portnummer ein ruter kan spore. Difor kan ein regel som tillèt TCP 1723 framleis la tunnelen vere utan datasti. Stateful NAT-einingar må forstå anrops-ID-en inne i GRE for å mappe svar tilbake, og mange gjer det ikkje. PPTP-spesifikasjonen held kontrollkanalen og GRE-nyttelasta som separate delar, og testplanen din må gjere det same.
Sjå etter protokoll 47 i same opptak, og samanlikn deretter det som går ut, med det som kjem tilbake:
sudo tcpdump -ni any 'proto gre' -c 20
Pakkar som går ut utan svar, medan TCP 1723 held seg sunt, er den klassiske signaturen på blokkert GRE. PPTP-passthrough på ein forbrukarruter er ein funksjon i akkurat den fastvaren, så eit fungerande hotellnettverk beviser ingenting om det neste. Viss ruteren ikkje tilbyr passthrough og du ikkje kan endre det, er problemet protokollvalet, ikkje rutetabellen.
Bevis at tunnelen flyttar éin pakke
Når GRE strøymer, tildeler PPP-forhandlinga ei adresse til klientgrensesnittet. Les tildelinga i staden for å anta henne:
ip -4 addr show ppp0
Ping peer-adressa som blir vist som destinasjon for punkt-til-punkt-sambandet. Eit svar på dette trinnet beviser at den innkapsla stien fungerer ende til ende, og at serveren svarer inne i tunnelen. Viss peeren svarer men interne vertar ikkje, er den ytre transporten i orden, og feilen har flytta seg innover.
Gjer dette før du legg til noka delt rute. Ei ruteendring som blir gjord medan transporten er øydelagd, skaper ein andre variabel og skjuler den første.
Skriv den delte politikken, inkludert DNS
Delt ruting er ei liste med avgjerder, ikkje ein avkryssingsboks. Kvar private prefiks som må krysse tunnelen treng ei rute gjennom PPP-grensesnittet, og kvar prefiks som må halde seg lokal må mangle i henne. Ei rute til eit applikasjonssubnett utan ei samsvarande rute til den private resolvaren sin er ein vanleg måte å lage eit avbrot som ser ut som ein øydelagd app.
Kontroller avgjerda kjernen tek for éi adresse i kvar kategori:
ip route get 10.20.5.10
ip route get 203.0.113.25
Den første skal nemne ppp0, den andre den vanlege gatewayen. Viss begge nemner same grensesnitt, er politikken ikkje delt i det heile. Legg DNS-serveren si eiga adresse til tunnellista, elles går namneoppslaget for interne vertar ut gjennom den lokale resolvaren og returnerer ingenting nyttig.
Ein repeterbar kontroll i fem trinn
Køyr laga i rekkjefølgje og stopp ved det første som feilar: kontrollkanal, GRE-synlegheit, PPP-peer-svar, delt rute for éi intern adresse, og ein applikasjonsførespurnad over tunnelen. Kvart trinn har sin eigen kommando, så ein feil kan tilskrivast i staden for å vere mystisk.
Ein kompakt versjon for ein 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 gjeld same rekkjefølgje med route print og adapterstatusen som blir vist i klienten. PPTP er ein eldre protokoll, og viss serveren tilbyr SSTP eller IKEv2, er det å flytte seg vanlegvis ein betre bruk av tida enn å finjustere ein sti som er avhengig av at protokoll 47 passerer kvar hopp. Kontroller sertifikatet og autentiseringskontrakten til erstatninga i staden for å kopiere ein gammal profil inn i ein ny versjon.