PPTP delad tunnel fungerar inte: reparera GRE-vägen först

Se en PPTP-anslutning komma upp och det är lätt att tro att det svåra är klart: klienten autentiserar sig, en ppp0-adapter eller WAN Miniport dyker upp och statusfönstret blir grönt. Sedan löper den första begäran till en intern värd ut i timeout och profilen får skulden. I praktiken finns två oberoende lager att reda ut: den yttre transporten som bär TCP 1723 och GRE, och den inre policyn som avgör vilka destinationer som använder PPP-gränssnittet. En grön status bevisar bara att det första lagret förhandlade; om det andra säger den ingenting.

Följ klienten från profil till kontrollsocket

Öppna klientloggen och hitta punkten där den kontaktar servern. PPTP öppnar först en TCP-anslutning till port 1723 och förhandlar tunnelparametrar över den kanalen. Om detta steg misslyckas spelar inget senare roll, och felet anger oftast serveradressen eller en timeout.

Bekräfta kontrollanslutningen på nätet innan du rör någon rutt. På klienten eller en spegelport fångar du TCP 1723 för ett anslutningsförsök:

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

Ett slutfört handskakning och en upprättad session betyder att den yttre kontrollkanalen fungerar. Ett SYN som aldrig får SYN-ACK pekar på en brandvägg, fel serveradress eller en leverantör som filtrerar porten. Ett handskakning följt av en omedelbar återställning betyder ofta att servern avvisade inloggningsuppgifterna eller tunneltypen.

GRE är ett andra protokoll, inte en port

PPTP bär PPP-nyttolasten inuti utökad GRE, IP-protokoll 47, som inte har något portnummer en router kan följa. Därför kan en regel som tillåter TCP 1723 ändå lämna tunneln utan dataväg. Stateful NAT-enheter måste förstå anrops-ID:t i GRE för att mappa svar tillbaka, och många gör det inte. PPTP-specifikationen håller kontrollkanalen och GRE-nyttolasten som separata delar, och din testplan måste göra detsamma.

Håll utkik efter protokoll 47 i samma inspelning och jämför sedan vad som går ut med vad som kommer tillbaka:

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

Paket som går ut utan svar, medan TCP 1723 förblir friskt, är den klassiska signaturen för blockerad GRE. PPTP-passthrough på en konsumentrouter är en funktion i just den firmwaren, så ett fungerande hotellnätverk bevisar ingenting om nästa. Om routern inte erbjuder passthrough och du inte kan ändra det, är problemet protokollvalet, inte routetabellen.

Bevisa att tunneln flyttar ett paket

När GRE flödar tilldelar PPP-förhandlingen en adress till klientgränssnittet. Läs tilldelningen i stället för att anta den:

ip -4 addr show ppp0

Pinga peer-adressen som visas som destination för punkt-till-punkt-länken. Ett svar i detta skede bevisar att den inkapslade vägen fungerar från ände till ände och att servern svarar inne i tunneln. Om peeren svarar men interna värdar inte, är den yttre transporten i ordning och felet har flyttat inåt.

Gör detta innan du lägger till någon delad rutt. En ruttändring som görs medan transporten är trasig skapar en andra variabel och döljer den första.

Skriv den delade policyn, inklusive DNS

Delad routing är en lista av beslut, inte en kryssruta. Varje privat prefix som måste korsa tunneln behöver en rutt genom PPP-gränssnittet, och varje prefix som måste stanna lokalt måste saknas i den. En rutt till ett applikationssubnät utan en matchande rutt till dess privata resolver är ett vanligt sätt att skapa ett avbrott som ser ut som en trasig app.

Kontrollera beslutet som kärnan fattar för en adress i varje kategori:

ip route get 10.20.5.10
ip route get 203.0.113.25

Den första ska ange ppp0, den andra den vanliga gatewayen. Om båda anger samma gränssnitt är policyn inte alls delad. Lägg till DNS-serverns egen adress i tunnellistan, annars går namuppslagningen för interna värdar ut genom den lokala resolvern och returnerar ingenting användbart.

En repeterbar kontroll i fem steg

Kör lagren i ordning och stanna vid det första som misslyckas: kontrollkanal, GRE-synlighet, PPP-peer-svar, delad rutt för en intern adress och en applikationsbegäran över tunneln. Varje steg har sitt eget kommando, så ett fel kan tillskrivas i stället för att vara mystiskt.

En kompakt version för en Linux-klient ser ut så här:

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 gäller samma ordning med route print och adapterstatusen som visas i klienten. PPTP är ett äldre protokoll, och om servern erbjuder SSTP eller IKEv2 är det att byta vanligtvis en bättre användning av tiden än att finjustera en väg som beror på att protokoll 47 passerar varje hopp. Kontrollera ersättningens certifikat och autentiseringsavtal i stället för att kopiera en gammal profil till en ny version.