PPTP opretter forbindelse og hænger derefter bag Linux NAT: GRE-hjælperen

Nogen videresender 1723, klienten når serveren, godkendelsen begynder, og så stopper alt uden en fejl. Den naturlige konklusion er en forkert adgangskode, så adgangskoden skrives ind tre gange. Videresendelsen var fin, og legitimationsoplysningerne var fine. Det, der gik i stykker, er en anden protokol, som videresendelsen aldrig dækkede, og en kerne-standard, der stille holdt op med at hjælpe med den.

Videresendelsen var aldrig problemet

En portvideresendelsesregel beskriver TCP- eller UDP-trafik. Den kan ikke beskrive en nyttelast, der midt i en session skifter til en anden IP-protokol, og PPTP gør præcis det.

Derfor ser forbindelsen sund ud lige indtil det øjeblik, den hænger. Den del, en portregel kan styre, lykkedes, og den del, den ikke kan styre, er den del, der fejlede.

TCP til kontrol, GRE til data

Kaldet forhandles over TCP 1723. Når det er oppe, flytter nyttelasten ind i GRE, IP-protokol 47, som slet ikke bærer portnumre. En regel, der bygger på porte, har intet at matche.

Det, GRE derimod bærer, er en kaldidentifikator i sit headere, og en NAT-oversætter skal skrive det felt konsekvent om i begge retninger, ellers holder de to halvdele af sessionen op med at være enige. Én retning omskrevet og den anden ikke giver en session, der godkender og derefter kasserer hver datapakke. Det er præcis symptomets form: succes, så tavshed.

Bart GRE uden PPTP kræver ingen sådan omskrivning, og derfor kan en almindelig GRE-tunnel fungere gennem en router, der fejler for en PPTP-klient på samme vej.

Fire moduler og en sysctl, der slog dem fra

To moduler håndterer indramningen, nf_conntrack_proto_gre og nf_nat_proto_gre. To mere håndterer kaldidentifikatoren, nf_conntrack_pptp og nf_nat_pptp. Indlæsning af den sidste af dem trækker resten ind via afhængigheder, så en modulliste bør vise alle fire.

Ældre instruktioner bruger et ip_-præfiks fra 2.6-tiden. De kommandoer kan se ud som om de kører, mens de ikke indlæser noget, så kontroller den indlæste liste i stedet for exitstatus.

At have dem indlæst er ikke nok længere. Siden Linux 4.7 har sysctl net.netfilter.nf_conntrack_helper standardværdien 0, hvilket slår automatisk tildeling af hjælpere fra for nye flows. En router kan have alle moduler og alligevel ikke oversætte noget. Kontroller den effektive værdi, før du ser på modullisten igen.

Slå enten automatisk tildeling til igen globalt, eller knyt hjælperen til de flows, der har brug for den, og lad alt andet være:

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

Den anden mulighed er den foretrukne. Den begrænser adfærden til PPTP-trafik i stedet for at genaktivere automatisk tildeling på hele routeren.

At åbne en protokol, der ikke har porte

En firewallregel, der tillader 1723, siger intet om protokol 47. På firewalld skal du tillade protokollen i zonen, der vender mod klienten. På almindelig iptables accepterer du protokol gre i inputkæden.

Fang derefter på begge sider. Pakker, der forlader klienten uden svar, der ankommer, betyder, at returvejen filtreres, og det er en anden fejl end en afvist legitimationsoplysning.

Når den har forbundet, størrelsesgrænsen

GRE indsætter et headere, og PPP indeni tilføjer mere, så et fungerende link rapporterer en MTU et godt stykke under 1500. Små svar indlæses, og store går i stå, hvilket ligner et andet, uafhængigt problem, der dukker op i det øjeblik, det første er løst.

Læs MTU'en på klientens PPP-adapter og afstem den med routerens egen beregning i stedet for at sænke tallene, indtil noget virker. Pakker i fuld størrelse, der går ud uden at noget kommer tilbage, peger på den grænse og ikke på oversættelsen.

At reparere vejen får brugeren til at virke, og det gør ikke PPTP til et godt valg. MS-CHAPv2 og RC4 er for længst forældede, så behandl modulindlæsningen som en midlertidig rettelse og planlæg et skift til en vedligeholdt protokol.