PPTP kobler til og henger deretter bak Linux NAT: GRE-hjelperen

Noen videresender 1723, klienten når serveren, autentiseringen begynner, og så stopper alt uten en feil. Den naturlige konklusjonen er feil passord, så passordet skrives inn tre ganger. Videresendingen var i orden, og legitimasjonen var i orden. Det som gikk i stykker, er en annen protokoll som videresendingen aldri dekket, og en kjerne-standardverdi som stille sluttet å hjelpe med den.

Videresendingen var aldri problemet

En portvideresendingsregel beskriver TCP- eller UDP-trafikk. Den kan ikke beskrive en nyttelast som bytter til en annen IP-protokoll midt i en økt, og PPTP gjør nøyaktig det.

Derfor ser forbindelsen sunn ut helt til øyeblikket den henger. Den delen en portregel kan styre, lyktes, og den delen den ikke kan styre, er den delen som feilet.

TCP for kontroll, GRE for data

Anropet forhandles over TCP 1723. Når det er oppe, flytter nyttelasten inn i GRE, IP-protokoll 47, som ikke bærer portnumre i det hele tatt. En regel som bygger på porter, har ingenting å matche.

Det GRE bærer, er en anropsidentifikator i overskriften, og en NAT-oversetter må skrive om det feltet konsekvent i begge retninger, ellers slutter de to halvdelene av økten å være enige. Én retning omskrevet og den andre ikke gir en økt som autentiserer og deretter forkaster hver datapakke. Det er nøyaktig formen på symptomet: suksess, så stillhet.

Bar GRE uten PPTP trenger ingen slik omskriving, og derfor kan en vanlig GRE-tunnel fungere gjennom en ruter som feiler for en PPTP-klient på samme vei.

Fire moduler og en sysctl som slo dem av

To moduler håndterer innrammingen, nf_conntrack_proto_gre og nf_nat_proto_gre. To til håndterer anropsidentifikatoren, nf_conntrack_pptp og nf_nat_pptp. Innlasting av den siste trekker de andre inn via avhengigheter, så en modulliste bør vise alle fire.

Eldre instruksjoner bruker et ip_-prefiks fra 2.6-tiden. Disse kommandoene kan se ut som de kjører mens de ikke laster noe, så sjekk den innlastede listen i stedet for exitstatusen.

Å ha dem lastet er ikke nok lenger. Siden Linux 4.7 har sysctl net.netfilter.nf_conntrack_helper standardverdien 0, noe som slår av automatisk tildeling av hjelpere for nye flyter. En ruter kan ha alle moduler og likevel ikke oversette noe. Sjekk den effektive verdien før du ser på modullisten igjen.

Slå enten automatisk tildeling på igjen globalt, eller koble hjelperen til flytene som trenger den og la alt annet være:

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

Det andre alternativet er å foretrekke. Det begrenser virkemåten til PPTP-trafikk i stedet for å gjenaktivere automatisk tildeling på hele ruteren.

Å åpne en protokoll som ikke har porter

En brannmurregel som tillater 1723, sier ingenting om protokoll 47. På firewalld tillater du protokollen i sonen som vender mot klienten. På vanlig iptables godtar du protokoll gre i inngangskjeden.

Ta så opptak på begge sider. Pakker som forlater klienten uten at svar kommer inn, betyr at returveien filtreres, og det er en annen feil enn avvist legitimasjon.

Etter at den har koblet til, størrelsesgrensen

GRE setter inn en overskrift, og PPP inni legger til mer, så en fungerende lenke rapporterer en MTU godt under 1500. Små svar lastes inn og store stopper, noe som ser ut som et annet, urelatert problem som dukker opp i det øyeblikket det første er løst.

Les MTU-en på klientens PPP-adapter og avstem den med ruterens egen beregning i stedet for å senke tallene til noe virker. Pakker i full størrelse som går ut uten at noe kommer tilbake, peker på den grensen og ikke på oversettelsen.

Å reparere veien får brukeren til å virke, og det gjør ikke PPTP til et godt valg. MS-CHAPv2 og RC4 er for lengst utdaterte, så behandle modulinnlastingen som en midlertidig rettelse og planlegg et skifte til en vedlikeholdt protokoll.