PPTP verbindt en blijft dan hangen achter Linux NAT: de GRE-helper

Iemand stuurt 1723 door, de client bereikt de server, de authenticatie begint en dan stopt alles zonder fout. De natuurlijke conclusie is een verkeerd wachtwoord, dus het wachtwoord wordt drie keer opnieuw getypt. De doorsturing was in orde en de inloggegevens waren in orde. Wat stukging is een tweede protocol dat de doorsturing nooit dekte, en een kernel-standaard die er stilletjes mee ophield te helpen.

De doorsturing was nooit het probleem

Een poortdoorstuurregel beschrijft TCP- of UDP-verkeer. Hij kan geen payload beschrijven die halverwege een sessie naar een ander IP-protocol overschakelt, en PPTP doet precies dat.

Daarom lijkt de verbinding gezond tot het moment dat hij hangt. Het deel dat een poortregel kan beheren, slaagde, en het deel dat hij niet kan beheren is het deel dat faalde.

TCP voor besturing, GRE voor gegevens

De oproep wordt over TCP 1723 onderhandeld. Zodra die staat, verhuist de payload naar GRE, IP-protocol 47, dat helemaal geen poortnummers draagt. Een regel die op poorten leunt, heeft niets om te vergelijken.

Wat GRE wél draagt is een oproepidentificatie in zijn header, en een NAT-vertaler moet dat veld consistent in beide richtingen herschrijven, anders houden de twee helften van de sessie op het met elkaar eens te zijn. Eén richting herschreven en de andere niet levert een sessie op die authenticeert en daarna elk datapakket weggooit. Dat is precies de vorm van het symptoom: succes, dan stilte.

Kaal GRE zonder PPTP heeft zo'n herschrijving niet nodig, daarom kan een gewone GRE-tunnel werken door een router die faalt voor een PPTP-client op hetzelfde pad.

Vier modules en een sysctl die ze uitzette

Twee modules verzorgen de framing, nf_conntrack_proto_gre en nf_nat_proto_gre. Twee andere verzorgen de oproepidentificatie, nf_conntrack_pptp en nf_nat_pptp. Het laden van de laatste trekt de rest via afhankelijkheden binnen, dus een modulelijst zou alle vier moeten tonen.

Oudere instructies gebruiken een ip_-prefix uit het 2.6-tijdperk. Die commando's kunnen lijken te draaien terwijl ze niets laden, dus controleer de geladen lijst in plaats van de exitstatus.

Ze geladen hebben is niet meer genoeg. Sinds Linux 4.7 staat de sysctl net.netfilter.nf_conntrack_helper standaard op 0, wat automatische helper-toewijzing voor nieuwe stromen uitschakelt. Een router kan elke module hebben en toch niets vertalen. Controleer de effectieve waarde voordat je de modulelijst opnieuw bekijkt.

Zet automatische toewijzing weer globaal aan, of koppel de helper aan de stromen die hem nodig hebben en laat al het andere met rust:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

De tweede optie heeft de voorkeur. Hij beperkt het gedrag tot PPTP-verkeer in plaats van automatische toewijzing op de hele router weer in te schakelen.

Een protocol openen dat geen poorten heeft

Een firewallregel die 1723 toestaat zegt niets over protocol 47. Op firewalld staat u het protocol toe in de zone die naar de client kijkt. Op gewone iptables accepteert u protocol gre in de input-keten.

Leg dan aan beide kanten af. Pakketten die de client verlaten zonder dat antwoorden aankomen, betekenen dat het retourpad wordt gefilterd, en dat is een andere fout dan een geweigerde inloggegevens.

Na de verbinding de groottelimiet

GRE voegt een header toe, en PPP daarbinnen voegt meer toe, dus een werkende link meldt een MTU ruim onder 1500. Kleine antwoorden laden en grote blijven hangen, wat lijkt op een tweede, ongerelateerd probleem dat opduikt op het moment dat het eerste is opgelost.

Lees de MTU op de PPP-adapter van de client en stem die af op de eigen berekening van de router in plaats van de getallen te verlagen tot iets werkt. Pakketten op volledige grootte die weggaan zonder dat er iets terugkomt, wijzen op die grens en niet op de vertaling.

Het pad repareren krijgt de gebruiker aan het werk, en het maakt PPTP geen goede keuze. MS-CHAPv2 en RC4 zijn allang verouderd, dus behandel het laden van de modules als een tijdelijke correctie en plan een overstap naar een onderhouden protocol.