PPTP via een hotspot: TCP 1723 is maar de helft

Werk de controles op volgorde af: of de besturingsverbinding opent, of GRE het pad overleeft, of de server de oproep accepteert en of de authenticatie voltooit. Een PPTP-client heeft zowel een TCP-sessie op 1723 als een GRE-pad dat de gegevens draagt nodig, en een hotspot kan het ene doorlaten en het andere laten vallen. Ze op volgorde doen vertelt je welke grens je moet onderzoeken in plaats van te gissen. Foutnummers van Windows doen dat niet voor je.

GRE is IP-protocol 47. Het is niet TCP- of UDP-poort 47, en dat onderscheid verklaart het grootste deel van de verwarring rond firewalls.

Twee paden, één verbinding

De besturingsverbinding is een gewone TCP-sessie naar bestemmingspoort 1723, die de meeste netwerken zonder klagen toestaan. Het gegevenspad is GRE, protocol 47, en een firewall die het eerste toestaat kan volledig onwetend zijn van het tweede. Die combinatie levert een client op die lijkt te starten en dan niets draagt, een veel minder informatieve symptoom dan een geweigerde verbinding. Test beide paden afzonderlijk voordat je iets over de provider concludeert.

Vertaling voegt zijn eigen eis toe. Gateways die poorten delen hebben vaak een PPTP-bewuste ALG nodig om oproep-ID's samen met adressen te herschrijven, en een zonder kan de sessie zo beschadigen dat het op pakketverlies lijkt. Dat gedrag is gebruikelijk maar implementatieafhankelijk, dus beschouw elke leveranciersbeperking als een voorbeeld en niet als een eigenschap van elke hotspot.

De hotspot voegt twee grenzen toe

Clientverkeer gaat meestal door de eigen deel-NAT van de telefoon en daarna door een vertaling op providerniveau voordat het de server bereikt. Een regel op de kantoorrouter kan een tussenbox van iemand anders niet repareren, daarom helpt port forwarding aan de thuiszijde zelden. Een uitgaande client heeft ook geen open inkomende poort nodig; antwoorden op een vertaalde verbinding komen terug via de status die de gateway heeft gemaakt. Een server die achter NAT wordt gehost heeft een heel andere set eisen.

Een menu-item met het label PPTP-passthrough, waar dat bestaat, bepaalt hoe dat apparaat dit protocol afhandelt. Het is niet dezelfde functie als een VPN op de telefoon hosten of elk protocol onvoorwaardelijk doorsturen, en het inschakelen ervan is geen algemene toestemming om GRE door te laten.

Lees 807 als een onderbreking, niet als een vonnis

Windows meldt 807 als een onderbroken verbinding, wat de uitkomst beschrijft in plaats van een oorzaak. De fouttabel behandelt 806 apart als de GRE-gerelateerde categorie, en dat verschil is de moeite waard om te kennen voordat je een theorie bouwt. Geen van beide nummers onthult of de provider protocol 47 filterde, of de server zonder capaciteit kwam te zitten, of de inloggegevens klopten. De fout zegt dat de sessie eindigde; het pad zegt waar.

Een browsertest die op de hotspot slaagt bewijst alleen dat een gewoon applicatiepad werkt. Over GRE zegt hij niets.

Isoleer de fase die faalde

Houd de laptop, de server en het profiel vast en wijzig dan alleen het toegangsnetwerk naar een ander goedgekeurd netwerk. Als het resultaat verandert, leg dan de TCP- en GRE-uitwisselingen vast bij de grenzen die je beheert en vind de vroegste fase die nooit gebeurt: besturingsopbouw, oproepopbouw, gegevenslevering of PPP-authenticatie. Elk laat een andere signatuur achter in een opname. Een werkend netwerk vergelijken met een falend netwerk is veel informatiever dan de fouttekst opnieuw lezen.

Dit alles diagnosticeert een implementatie die al bestaat. Het is geen argument om een nieuwe PPTP-dienst op te zetten, en het protocol laat zich niet weggonderhandelen: een andere client installeren maakt een ongewijzigde server niet iets anders spreken.

Voor blijvende toegang, spreek een ondersteunde migratie af met de eigenaar van de VPN. De checklist eindigt met een beslissing in plaats van een omweg.