PPTP-verdeelde tonnel werk nie: maak die GRE-pad eerste reg

Kyk hoe 'n PPTP-verbinding opkom en dit is maklik om te glo die moeilike deel is klaar: die kliënt verifieer, 'n ppp0-adapter of WAN Miniport verskyn, en die statusvenster word groen. Dan verstryk die eerste versoek aan 'n interne gasheer, en die profiel kry die skuld. In die praktyk is daar twee onafhanklike lae om skoon te maak, die buitenste vervoer wat TCP 1723 en GRE dra, en die binneste beleid wat besluit watter bestemmings die PPP-koppelvlak gebruik. 'n Groen status bewys net dat die eerste laag onderhandel het; dit sê niks oor die tweede nie.

Volg die kliënt van profiel tot beheersokket

Maak die kliëntlog oop en vind die punt waar dit die bediener kontak. PPTP maak eers 'n TCP-verbinding na poort 1723 oop en onderhandel tonnelparameters oor daardie kanaal. As hierdie stap misluk, maak niks later saak nie, en die fout noem gewoonlik die bedieneradres of 'n verstryking.

Bevestig die beheerverbinding op die draad voordat jy enige roete aanraak. Op die kliënt of 'n spieëlpoort, vang TCP 1723 vir een verbindingspoging:

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

Voltooide handdruk en 'n gevestigde sessie beteken die buitenste beheerkanaal werk. 'n SYN wat nooit 'n SYN-ACK kry nie, wys op 'n brandmuur, 'n verkeerde bedieneradres, of 'n verskaffer wat die poort filter. 'n Handdruk gevolg deur 'n onmiddellike herstel beteken dikwels die bediener het die geloofsbriewe of die tonneltipe verwerp.

GRE is 'n tweede protokol, nie 'n poort nie

PPTP dra die PPP-lading binne versterkte GRE, IP-protokol 47, wat geen poortnommer het vir 'n router om na te spoor nie. Dit is waarom 'n reël wat TCP 1723 toelaat, die tonnel steeds sonder 'n datapad kan laat. Toestandbeheerende NAT-toestelle moet die oproep-ID binne GRE verstaan om antwoorde terug te kaart, en baie doen dit nie. Die PPTP-spesifikasie hou die beheerkanaal en die GRE-lading as aparte stukke, en so moet jou toetsplan ook.

Kyk vir protokol 47 in dieselfde opname, en vergelyk dan wat uitgaan met wat terugkom:

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

Pakette wat uitgaan sonder antwoorde, terwyl TCP 1723 gesond bly, is die klassieke geblokkeerde-GRE-handtekening. PPTP-deurlaat op 'n verbruikersrouter is 'n eienskap van daardie spesifieke fermware, so 'n werkende hotelnetwerk bewys niks oor die volgende een nie. As die router geen deurlaat bied nie en jy kan dit nie verander nie, is die protokolkeuse die probleem, nie die roetetabel nie.

Bewys die tonnel beweeg een pakket

Sodra GRE vloei, ken PPP-onderhandeling 'n adres aan die kliëntkoppelvlak toe. Lees die toewysing eerder as om dit te aanvaar:

ip -4 addr show ppp0

Ping die eweknie-adres wat as die bestemming van die punt-tot-punt-skakel gewys word. 'n Antwoord op hierdie stadium bewys die ingekapselde pad werk van begin tot einde en dat die bediener binne die tonnel antwoord. As die eweknie antwoord maar interne gashere nie, is die buitenste vervoer reg en het die fout na binne geskuif.

Doen dit voordat jy enige gesplete roete byvoeg. 'n Roeteverandering terwyl die vervoer stukkend is, skep 'n tweede veranderlike en verberg die eerste.

Skryf die gesplete beleid, DNS ingesluit

Gesplete roetering is 'n lys besluite, nie 'n merkblokkie nie. Elke private voorvoegsel wat die tonnel moet kruis, benodig 'n roete deur die PPP-koppelvlak, en elke voorvoegsel wat plaaslik moet bly, moet daaruit afwesig wees. 'n Roete vir 'n toepassingsubnet sonder 'n ooreenstemmende roete na sy private oplosser is 'n algemene manier om 'n onderbreking te skep wat soos 'n stukkende app lyk.

Kyk na die besluit wat die kern vir een adres in elke kategorie maak:

ip route get 10.20.5.10
ip route get 203.0.113.25

Die eerste moet ppp0 noem, die tweede die gewone gateway. As albei dieselfde koppelvlak noem, is die beleid glad nie gesplete nie. Voeg die DNS-bediener se eie adres by die tonnellys, anders verlaat naamresolusie vir interne gashere deur die plaaslike oplosser en lewer niks nuttigs nie.

'n Herhaalbare kontrole in vyf stappe

Voer die lae in volgorde uit en stop by die eerste een wat misluk: beheerkanaal, GRE-sigbaarheid, PPP-eweknie-antwoord, gesplete roete vir een interne adres, en 'n toepassingsversoek oor die tonnel. Elke stap het sy eie opdrag, so 'n mislukking is toeskryfbaar eerder as geheimsinnig.

'n Kompakte weergawe vir 'n Linux-kliënt lyk so:

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

Op Windows geld dieselfde volgorde met route print en die adapterstatus wat in die kliënt gewys word. PPTP is 'n nalatenskapprotokol, en as die bediener SSTP of IKEv2 bied, is om te skuif gewoonlik 'n beter gebruik van tyd as om 'n pad te stroop wat daarop staatmaak dat protokol 47 elke hop slaag. Kontroleer die vervanging se sertifikaat en verifikasiekontrak eerder as om 'n ou profiel in 'n nuwe weergawe te kopieer.