PPTP split tunneling werkt niet: repareer eerst het GRE-pad

Zie een PPTP-verbinding opkomen en het is gemakkelijk te geloven dat het moeilijke deel klaar is: de client authenticeert, een ppp0-adapter of WAN Miniport verschijnt, en het statusvenster wordt groen. Dan loopt het eerste verzoek naar een interne host in een time-out en krijgt het profiel de schuld. In de praktijk zijn er twee onafhankelijke lagen te ontdoen: het buitenste transport dat TCP 1723 en GRE draagt, en het binnenste beleid dat bepaalt welke bestemmingen de PPP-interface gebruiken. Een groene status bewijst alleen dat de eerste laag heeft onderhandeld; over de tweede zegt hij niets.

Volg de client van profiel tot controlesocket

Open het clientlog en vind het punt waarop hij de server contacteert. PPTP opent eerst een TCP-verbinding naar poort 1723 en onderhandelt de tunnelparameters over dat kanaal. Als deze stap mislukt, doet niets later ertoe, en de fout noemt meestal het serveradres of een time-out.

Bevestig de controleverbinding op de lijn voordat u een route aanraakt. Op de client of een spiegelpoort legt u TCP 1723 vast voor één verbindingspoging:

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

Een voltooide handdruk en een opgezette sessie betekenen dat het buitenste controlekanaal werkt. Een SYN dat nooit een SYN-ACK krijgt, wijst op een firewall, een verkeerd serveradres of een provider die de poort filtert. Een handdruk gevolgd door een onmiddellijke reset betekent vaak dat de server de inloggegevens of het tunneltype heeft geweigerd.

GRE is een tweede protocol, geen poort

PPTP draagt de PPP-payload in uitgebreide GRE, IP-protocol 47, dat geen poortnummer heeft dat een router kan volgen. Daarom kan een regel die TCP 1723 toestaat de tunnel nog steeds zonder datapad achterlaten. Stateful NAT-apparaten moeten de call-ID in GRE begrijpen om antwoorden terug te mappen, en veel doen dat niet. De PPTP-specificatie houdt het controlekanaal en de GRE-payload als aparte onderdelen, en dat moet uw testplan ook doen.

Let op protocol 47 in dezelfde opname en vergelijk dan wat eruit gaat met wat er terugkomt:

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

Pakketten die zonder antwoorden naar buiten gaan, terwijl TCP 1723 gezond blijft, zijn de klassieke signatuur van geblokkeerde GRE. PPTP-passthrough op een consumentenrouter is een functie van die specifieke firmware, dus een werkend hotelnetwerk bewijst niets over het volgende. Biedt de router geen passthrough en kunt u hem niet wijzigen, dan is de protocolkeuze het probleem, niet de routetabel.

Bewijs dat de tunnel één pakket verplaatst

Zodra GRE stroomt, wijst de PPP-onderhandeling een adres toe aan de clientinterface. Lees de toewijzing in plaats van haar aan te nemen:

ip -4 addr show ppp0

Ping het peeradres dat als bestemming van de punt-tot-puntverbinding wordt getoond. Een antwoord in deze fase bewijst dat het ingekapselde pad van begin tot eind werkt en dat de server binnen de tunnel antwoordt. Als de peer antwoordt maar interne hosts niet, is het buitenste transport in orde en is de storing naar binnen verhuisd.

Doe dit voordat u een gesplitste route toevoegt. Een routewijziging tijdens een kapot transport creëert een tweede variabele en verbergt de eerste.

Schrijf het gesplitste beleid, inclusief DNS

Gesplitst routeren is een lijst met beslissingen, geen selectievakje. Elk privéprefix dat de tunnel moet passeren heeft een route via de PPP-interface nodig, en elk prefix dat lokaal moet blijven moet daarin ontbreken. Een route naar een applicatiesubnet zonder bijpassende route naar de privé-resolver ervan is een veelvoorkomende manier om een storing te maken die op een kapotte app lijkt.

Controleer de beslissing die de kernel voor één adres in elke categorie neemt:

ip route get 10.20.5.10
ip route get 203.0.113.25

De eerste moet ppp0 noemen, de tweede de gewone gateway. Als beide dezelfde interface noemen, is het beleid helemaal niet gesplitst. Voeg het adres van de DNS-server zelf toe aan de tunnellijst, anders verlaat naamresolutie voor interne hosts de lokale resolver en levert niets bruikbaars op.

Een herhaalbare controle in vijf stappen

Voer de lagen in volgorde uit en stop bij de eerste die faalt: controlekanaal, GRE-zichtbaarheid, PPP-peerantwoord, gesplitste route voor één intern adres, en een applicatieverzoek over de tunnel. Elke stap heeft zijn eigen commando, dus een storing is toerekenbaar in plaats van mysterieus.

Een compacte versie voor een Linux-client ziet er zo uit:

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 geldt dezelfde volgorde met route print en de adapterstatus die in de client wordt getoond. PPTP is een verouderd protocol, en als de server SSTP of IKEv2 biedt, is overstappen meestal een beter gebruik van tijd dan het tunen van een pad dat afhangt van protocol 47 dat elke hop passeert. Controleer het certificaat en het authenticatiecontract van de vervanging in plaats van een oud profiel naar een nieuwe versie te kopiëren.