PPTP verbind en hang dan agter Linux NAT: die GRE-hulpmodule

Iemand stuur 1723 aan, die kliënt bereik die bediener, verifikasie begin, en dan stop alles sonder ’n fout. Die natuurlike gevolgtrekking is ’n verkeerde wagwoord, so die wagwoord word drie keer oorgetik. Die aanstuur was reg en die geloofsbriewe was reg. Wat gebreek het, is ’n tweede protokol wat die aanstuur nooit gedek het nie, en ’n kernel-verstek wat stilweg opgehou het om daarmee te help.

Die aanstuur was nooit die probleem nie

’n Poortaanstuur-reël beskryf TCP- of UDP-verkeer. Dit kan nie ’n payload beskryf wat halfpad deur ’n sessie na ’n ander IP-protokol oorskakel nie, en PPTP doen presies dit.

Dit is hoekom die verbinding gesond lyk tot die oomblik dat dit hang. Die deel wat ’n poortreël kan beheer, het geslaag, en die deel wat dit nie kan beheer nie, is die deel wat gefaal het.

TCP vir beheer, GRE vir data

Die oproep word oor TCP 1723 onderhandel. Sodra dit op is, beweeg die payload in GRE in, IP-protokol 47, wat glad geen poortnommers dra nie. ’n Reël wat op poorte sleutel, het niks om op te pas nie.

Wat GRE wel dra, is ’n oproepidentifiseerder in sy kop, en die NAT-omsetter moet daardie veld konsekwent in beide rigtings herskryf, anders hou die twee helftes van die sessie op om met mekaar saam te stem. Een rigting herskryf en die ander nie lewer ’n sessie wat verifieer en dan elke datapakket weggooi. Dit is presies die vorm van die simptoom: sukses, dan stilte.

Kaal GRE sonder PPTP het geen sulke herskrywing nodig nie, en daarom kan ’n gewone GRE-tonnel deur ’n router werk wat vir ’n PPTP-kliënt op dieselfde pad faal.

Vier modules en ’n sysctl wat hulle afgeskakel het

Twee modules hanteer die raamwerk, nf_conntrack_proto_gre en nf_nat_proto_gre. Nog twee hanteer die oproepidentifiseerder, nf_conntrack_pptp en nf_nat_pptp. Om die laaste van dié te laai, trek die res deur afhanklikhede in, so ’n modulelys moet al vier wys.

Ouer instruksies gebruik ’n ip_-voorvoegsel uit die 2.6-era. Daardie opdragte kan dit lyk of hulle uitvoer terwyl niks gelaai word nie, so kyk na die gelaai lys eerder as die afsluitstatus.

Om hulle gelaai te hê, is nie meer genoeg nie. Sedert Linux 4.7 het die sysctl net.netfilter.nf_conntrack_helper ’n verstekwaarde van 0, wat outomatiese helper-toewysing vir nuwe strome deaktiveer. ’n Router kan elke module hê en steeds niks vertaal nie. Kyk na die effektiewe waarde voordat jy weer na die modulelys kyk.

Skakel outomatiese toewysing weer globaal aan, of koppel die helper aan die strome wat dit nodig het en los alles anders alleen:

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

Die tweede opsie is die een om te verkies. Dit beperk die gedrag tot PPTP-verkeer in plaas daarvan om outomatiese toewysing oor die hele router te heraktiveer.

Om ’n protokol oop te maak wat geen poorte het nie

’n Brandmuurreël wat 1723 toelaat, sê niks oor protokol 47 nie. Op firewalld laat jy die protokol toe op die sone wat na die kliënt wys. Op gewone iptables aanvaar jy protokol gre in die input-ketting.

Vang dan aan beide kante. Pakkette wat die kliënt verlaat sonder dat antwoorde aankom, beteken die terugpad word gefiltreer, en dit is ’n ander fout as ’n verwerpte geloofsbrief.

Nadat dit verbind het, die groottelimiet

GRE voeg ’n kop by, en PPP daarbinne voeg nog meer by, so ’n werkende skakel rapporteer ’n MTU ver onder 1500. Klein antwoorde laai en groot antwoorde hang, wat lyk soos ’n tweede, onverwante probleem wat verskyn sodra die eerste een opgelos is.

Lees die MTU op die kliënt se PPP-adapter en bring dit in ooreenstemming met die router se eie berekening in plaas daarvan om die nommers te verlaag tot iets werk. Volgrootte-pakkette wat uitgaan sonder dat iets terugkom, dui op daardie limiet eerder as op die adresomsetting.

Om die pad te herstel kry die gebruiker aan die werk, en dit maak PPTP nie ’n goeie keuse nie. MS-CHAPv2 en RC4 is lank reeds afgeskaf, so behandel die modulelaai as ’n tydelike regstelling en beplan ’n skuif na ’n onderhoude protokol.