PPTP koplar til og heng så bak Linux NAT: GRE-hjelparen

Nokon videresender 1723, klienten når serveren, autentiseringa byrjar, og så stoggar alt utan ein feil. Den naturlege konklusjonen er feil passord, så passordet blir skrive inn tre gonger. Videresendinga var i orden, og legitimasjonen var i orden. Det som gjekk i stykker, er ein annan protokoll som videresendinga aldri dekte, og ein kjerne-standardverdi som stille slutta å hjelpe med han.

Videresendinga var aldri problemet

Ein portvideresendingsregel skildrar TCP- eller UDP-trafikk. Han kan ikkje skildre ein nyttelast som byter til ein annan IP-protokoll midt i ei økt, og PPTP gjer nøyaktig det.

Difor ser sambandet sunt ut heilt til augneblinken det heng. Den delen ein portregel kan styre, lukkast, og den delen han ikkje kan styre, er den delen som feila.

TCP for kontroll, GRE for data

Anropet blir forhandla over TCP 1723. Når det er oppe, flyttar nyttelasten inn i GRE, IP-protokoll 47, som ikkje ber portnummer i det heile. Ein regel som byggjer på portar, har ingenting å matche.

Det GRE ber, er ein anropsidentifikator i overskrifta, og ein NAT-omsetjar må skrive om det feltet konsekvent i begge retningar, elles sluttar dei to halvdelane av økta å vere samde. Éi retning omskriven og den andre ikkje gir ei økt som autentiserer og deretter forkastar kvar datapakke. Det er nøyaktig forma på symptomet: suksess, så stille.

Ber GRE utan PPTP treng ingen slik omskriving, og difor kan ein vanleg GRE-tunnel fungere gjennom ein ruter som feilar for ein PPTP-klient på same veg.

Fire modular og ein sysctl som slo dei av

To modular handterer innramminga, nf_conntrack_proto_gre og nf_nat_proto_gre. To til handterer anropsidentifikatoren, nf_conntrack_pptp og nf_nat_pptp. Innlasting av den siste dreg dei andre inn via avhengnader, så ei modulliste bør vise alle fire.

Eldre instruksjonar brukar eit ip_-prefiks frå 2.6-tida. Desse kommandoane kan sjå ut som dei køyrer medan dei ikkje lastar noko, så sjekk den innlasta lista i staden for exitstatusen.

Å ha dei lasta er ikkje nok lenger. Sidan Linux 4.7 har sysctl net.netfilter.nf_conntrack_helper standardverdien 0, noko som slår av automatisk tildeling av hjelparar for nye flytar. Ein ruter kan ha alle modular og likevel ikkje omsetje noko. Sjekk den effektive verdien før du ser på modullista igjen.

Slå anten på automatisk tildeling igjen globalt, eller kople hjelparen til flytane som treng han og la alt anna vere:

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

Det andre alternativet er å føretrekkje. Det avgrensar verkemåten til PPTP-trafikk i staden for å gjenaktivere automatisk tildeling på heile ruteren.

Å opne ein protokoll som ikkje har portar

Ein brannmurregel som tillèt 1723, seier ingenting om protokoll 47. På firewalld tillèt du protokollen i sona som vender mot klienten. På vanleg iptables godtek du protokoll gre i inngangskjeda.

Ta så opptak på begge sider. Pakkar som forlét klienten utan at svar kjem inn, tyder at returvegen blir filtrert, og det er ein annan feil enn avvist legitimasjon.

Etter at han har kopla til, storleiksgrensa

GRE set inn ei overskrift, og PPP inni legg til meir, så ei fungerande lenkje rapporterer ein MTU godt under 1500. Små svar lastar og store stoppar, noko som ser ut som eit anna, urelatert problem som dukkar opp i augneblinken det første er løyst.

Les MTU-en på PPP-adapteren til klienten og stem han av med ruteren si eiga berekning i staden for å senke tala til noko verkar. Pakkar i full storleik som går ut utan at noko kjem tilbake, peikar på den grensa og ikkje på omsetjinga.

Å reparere vegen får brukaren til å verke, og det gjer ikkje PPTP til eit godt val. MS-CHAPv2 og RC4 er for lengst utdaterte, så handsam innlastinga av modulane som ei mellombels retting og planlegg eit skifte til ein vedlikehalden protokoll.