PPTP-server achter een thuisrouter: repareer eerst 1723 en GRE

PPTP achter een thuisrouter faalt op twee losse manieren, en ze door elkaar halen kost een hele avond. Eén storing is een gat in de doorsturing: de router laat TCP 1723 door en gooit IP-protocol 47 weg, waardoor de client blijft hangen op fout 619. De andere is een grootteprobleem: de tunnel komt op, authenticeert en bevriest vervolgens wanneer een pakket van volledige grootte moet passeren. Uitzoeken welke van de twee je hebt is de eerste echte stap; de rest vergelijkt wat je router kan uitdrukken, niet welk merk beter is.

Twee transporten, en slechts één heeft een poort

PPTP valt uiteen in twee transporten: een controleverbinding op TCP 1723 en PPP-frames verpakt in uitgebreide GRE, dat is IP-protocol 47. GRE heeft geen poortnummer, dus een regel die is geschreven als doorsturen van poort 1723 kan het niet dekken, hoe de webinterface het veld ook noemt. Een thuisrouter biedt meestal een vakje met de naam PPTP-passthrough in plaats van een protocolregel, en dat vakje doet twee dingen: het laat protocol 47 door de firewall en het leert NAT de GRE-stroom te volgen. Op een Linux-router zijn die taken aparte modules en aparte regels, waardoor een half geconfigureerde passthrough nog steeds een werkend controlekanaal oplevert. Zoek uit welke helft aanwezig is voordat je iets verandert.

De firewall van de server zelf moet ook protocol 47 vanaf het routeradres toestaan. Een hostfirewall die alleen 1723/tcp accepteert, reproduceert fout 619 van binnen het LAN, waardoor een kapotte doorsturing en een kapotte hostregel identiek lijken.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

Als de modules ontbreken, laad ze dan met sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre en maak het laden permanent, want een herstart die de helper vergeet, maakt van een werkende tunnel weer fout 619. De doorstuurregel hoeft protocol 47 alleen naar het serveradres toe te staan, niet het hele LAN. De definitie in RFC 2637 scheidt het controle- en het datapad, en daarom beschrijft geen enkel scherm voor poortdoorsturing PPTP volledig.

Passthrough-vakje of een expliciete protocolregel

Een passthrough-vakje dat alleen de firewall opent, zit dichter bij het juiste dan een ALG die oproep-ID's herschrijft. De firewallhelft is voorspelbaar, want protocol 47 wordt ofwel geaccepteerd ofwel weggegooid, en de tellers zeggen welke. De herschrijfhelft is waar fabrikanten verschillen, omdat PPTP-oproep-ID's per tunnel gelden en een NAT die ze bewerkt elke oproep moet volgen die hij aanraakt. Wanneer één client verbindt en twee niet, is de ALG de eerste verdachte.

Een destination-NAT-regel voor 1723 heeft ook een eigendomsprobleem. Als een oude regel 1723 nog naar een host stuurt die de server niet meer draait, belanden pakketten op een gesloten poort en stopt de eigen PPTP-dienst van de router met antwoorden, wat leest als een firewallfout maar in werkelijkheid een verouderd doel is. Lees de regel en het doel voordat je een tweede toevoegt. Op routers die PPTP zelf beëindigen, concurreert de WAN-regel met de ingebouwde dienst, dus kies één eigenaar voor 1723 en protocol 47.

Twee clients achter dezelfde NAT is het geval dat een eenvoudige doorsturing van een slimme scheidt. Protocol 47 doorsturen zonder de oproep-ID's te herschrijven gedraagt zich meestal beter dan een helper die ze probeert te repareren.

Meet de tunnel voordat je de router de schuld geeft

PPTP verkleint de bruikbare lading, en die verkleining is rekenkunde, geen mysterie. Elk tunnelpakket draagt een buitenste IP-header, een uitgebreide GRE-header, een PPP-header en, met versleuteling, een MPPE-header. Wanneer het pad de resulterende frame niet kan dragen, gaan kleine pakketten door, de aanmelding voltooit, en de sessie stopt de eerste keer dat een bestandsoverdracht of een TLS-handshake een pakket van volledige grootte verstuurt.

Reken het getal uit in plaats van het te raden. Uitgebreide GRE kost 8 bytes, PPP kost 4, MPPE kost 4, en de buitenste IP-header kost 20, dus de tunnel eet 36 bytes voordat er enige lading is. Op een PPPoE-WAN die op 1492 eindigt, is de grootste PPP-MTU die past 1492 min 36, dus 1456. Zet mtu en mru op die waarde in de PPP-opties en test opnieuw met een ping zonder fragmentatie.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

De ping meet het pad, niet de tunnel: 1464 bytes lading plus 28 bytes IP- en ICMP-headers vullen precies een frame van 1492 bytes. Als die ping faalt, verlaag het getal tot het lukt en trek 36 van het resultaat af. Een tunnel-MTU boven de limiet van het pad levert de bevriezing zonder één logregel die de grootte noemt.

PPTP, L2TP/IPsec of OpenVPN op dezelfde router

Dezelfde router kan elk van de drie gangbare tunnels dragen, en het verschil is wat hij moet uitdrukken. PPTP heeft twee regels in twee verschillende lagen nodig. L2TP over IPsec heeft UDP 500 en 4500 nodig voor de sleuteluitwisseling en, tenzij NAT-T het draagt, protocol 50 voor de lading. OpenVPN heeft één UDP-poort nodig en helemaal geen helper.

De L2TP-kolom is niet automatisch vriendelijker dan GRE. ESP is IP-protocol 50 en heeft ook geen poort, dus een router die moeite heeft met protocol 47 kan om dezelfde reden moeite hebben met protocol 50. NAT-T bestaat om ESP in UDP 4500 te verpakken, en wanneer beide uiteinden het ondersteunen wordt de protocol-50-regel overbodig. Dat is een eigenschap van de uiteinden, niet van het PPTP-vakje van de router. Bevestig welke inkapseling de client werkelijk heeft onderhandeld voordat je regels voor beide schrijft.

OpenVPN is de optie met de minste bewegende delen aan de routerkant. Eén UDP-poort, één doorsturing, geen hulpprogramma voor verbindingsregistratie en geen herschrijving van oproep-ID's. De ruil is een client die moet worden geïnstalleerd in plaats van een ingebouwde kiezer, en dat is vaak de enige reden waarom PPTP in het gesprek blijft.

Wat te repareren en wat te vervangen

De doorsturing en de MTU repareren geeft je een tunnel die werkt, niet een die je moet houden. De MSCHAPv2-authenticatie van PPTP is al jaren aanvalbaar, en een werkende tunnel verplaatst inloggegevens die offline kunnen worden hersteld. Als het externe apparaat L2TP/IPsec of OpenVPN kan draaien, behandel de reparatie dan als een tijdelijke maatregel met een datum.

De beslissing komt neer op wat de andere kant ondersteunt en hoe lang de regeling moet blijven. Een oud apparaat dat alleen PPTP spreekt, krijgt de reparatie; alles wat een client kan installeren, wordt gemigreerd.

Voordat je het ticket sluit, bevestig dat de client een grote overdracht overleeft en niet alleen een aanmelding, en dat de router na een herstart nog steeds zijn protocol-47-regel vasthoudt. Een tunnel die één bestandskopie haalt en sterft na de volgende firmware-update was nooit af.