PPTP ferbynt en hinget dan efter Linux NAT: de GRE-helper

Immen stjoert 1723 troch, de klant berikt de tsjinner, autentikaasje begjint, en dan stiet alles stil sûnder flater. De natuerlike konklúzje is in ferkeard wachtwurd, dus it wachtwurd wurdt trije kear opnij typt. De trochstjoering wie goed en de oanmeldgegevens wiene goed. Wat brutsen is, is in twadde protokol dat de trochstjoering nea omfette, en in kernelstandert dy't stil ophold derby te helpen.

De trochstjoering wie nea it probleem

In poartetrochstjoeringsregel beskriuwt TCP- of UDP-ferkear. Hy kin gjin lading beskriuwe dy't healwei in sesje oerstapt nei in oar IP-protokol, en PPTP docht krekt dat.

Dêrom liket de ferbining sûn oant it momint dat se hinget. It diel dat in poarteregel bestjoere kin, slagge, en it diel dat er net bestjoere kin, is it diel dat mislearre.

TCP foar kontrôle, GRE foar gegevens

De oprop wurdt oer TCP 1723 ûnderhannele. As dy stiet, ferhúzet de lading nei GRE, IP-protokol 47, dat hielendal gjin poartnûmers draacht. In regel dy't op poarten stipet, hat neat om te ferlykjen.

Wat GRE wol draacht, is in propidentifikaasje yn syn kop, en in NAT-oersetter moat dat fjild konsekwint yn beide rjochtingen oerskriuwe, oars hâlde de twa helten fan 'e sesje op mei oerien te kommen. Ien rjochting oerskreaun en de oare net jout in sesje dy't autentisearret en dan elk datapakket fuortsmyt. Dat is krekt de foarm fan it symptoom: sukses, dan stilte.

Neaken GRE sûnder PPTP hat sa'n oerskriuwing net nedich, dêrom kin in gewoane GRE-tunnel troch in router wurkje dy't foar in PPTP-klant op itselde paad mislearret.

Fjouwer modules en in sysctl dy't se útskeakele

Twa modules dogge de raming, nf_conntrack_proto_gre en nf_nat_proto_gre. Twa oaren dogge de propidentifikaasje, nf_conntrack_pptp en nf_nat_pptp. It laden fan de lêste lûkt de rest fia ôfhinklikens nei binnen, dus in modulelist moat alle fjouwer sjen litte.

Aldere ynstruksjes brûke in ip_-foarheaksel út it 2.6-tiidrek. Dy opdrachten kinne lykje as rinne se wylst se neat lade, dus kontrolearje de laden list ynstee fan 'e útgongstatus.

Se laden hawwe is net genôch mear. Sûnt Linux 4.7 is de sysctl net.netfilter.nf_conntrack_helper standert 0, wat automatyske helper-tawizing foar nije streams útskeakelet. In router kin elke module hawwe en dochs neat oersette. Kontrolearje de effektive wearde foardat jo de modulelist wer besjen.

Skeakelje automatyske tawizing wer globaal oan, of koppelje de helper oan 'e streams dy't him nedich hawwe en lit al it oare gewurde:

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

De twadde opsje is de foarkar. It beheint it gedrach ta PPTP-ferkear ynstee fan automatyske tawizing oer de hiele router wer oan te setten.

In protokol iepenje dat gjin poarten hat

In firewallregel dy't 1723 tastiet, seit neat oer protokol 47. Lit op firewalld it protokol ta yn 'e sône dy't nei de klant rjochte is. Akseptearje op gewoane iptables it protokol gre yn 'e ynfierketen.

Fang dan oan beide kanten. Pakketten dy't de klant ferlitte sûnder dat antwurden oankomme, betsjutte dat it werompaad filtere wurdt, en dat is in oare flater as in wegere oanmeldgegevens.

Nei't it ferbûn is, de grins oan 'e grutte

GRE foeget in kop ta, en PPP deryn foeget mear ta, dus in wurkjende keppeling rapportearret in MTU fier ûnder 1500. Lytse antwurden lade en grutte stûkje, wat liket as in twadde, net besibbe probleem dat ferskynt op it stuit dat it earste oplost is.

Lês de MTU op 'e PPP-adapter fan 'e klant en bring dy yn oerienstimming mei de eigen berekkening fan 'e router ynstee fan de nûmers te ferleegjen oant iets wurket. Pakketten fan folsleine grutte dy't fuortgeane sûnder dat der wat weromkomt, wize op dy grins en net op 'e oersetting.

It paad reparearje krijt de brûker oan it wurk, en it makket PPTP gjin goede kar. MS-CHAPv2 en RC4 binne al lang ferâldere, dus behannelje it laden fan de modules as in tydlike repaaraazje en plan in oerstap nei in ûnderhâlden protokol.