PPTP ühendub ja jääb siis Linux NAT-i taga rippuma: GRE abiline

Keegi suunab 1723 edasi, klient jõuab serverini, autentimine algab ja siis kõik peatub ilma veata. Loomulik järeldus on vale parool, nii et parool trükitakse kolm korda uuesti. Edasisuunamine oli korras ja volitused olid korras. Katki läks teine protokoll, mida edasisuunamine kunagi ei katnud, ja kerneli vaikeväärtus, mis lakkas vaikselt sellega aitamast.

Edasisuunamine ei olnud kunagi probleem

Pordi edasisuunamise reegel kirjeldab TCP või UDP liiklust. See ei saa kirjeldada koormust, mis keset seanssi läheb üle teisele IP-protokollile, ja PPTP teeb täpselt seda.

Seetõttu näeb ühendus terve välja kuni hetkeni, mil see rippuma jääb. Osa, mida pordireegel suudab juhtida, õnnestus, ja osa, mida see juhtida ei suuda, ongi see osa, mis ebaõnnestus.

TCP juhtimiseks, GRE andmete jaoks

Kõne peetakse üle TCP 1723. Kui see püsti saab, liigub koormus GRE-sse, IP-protokoll 47, mis ei kanna üldse pordinumbreid. Reeglil, mis põhineb portidel, pole millegagi sobida.

GRE kannab päises kõne identifikaatorit ja NAT-tõlkija peab selle välja mõlemas suunas järjekindlalt ümber kirjutama, muidu lakkavad seansi kaks poolt omavahel kokku leppimast. Üks suund ümber kirjutatud ja teine mitte annab seansi, mis autendib ja seejärel viskab kõik andmepaketid kõrvale. Täpselt selline ongi sümptomi kuju: edu, siis vaikus.

Paljas GRE ilma PPTP-ta ei vaja sellist ümberkirjutust, seepärast võib tavaline GRE-tunnel töötada ruuteri kaudu, mis samal teel PPTP-kliendi jaoks ebaõnnestub.

Neli moodulit ja sysctl, mis need välja lülitas

Kaks moodulit tegelevad raamimisega, nf_conntrack_proto_gre ja nf_nat_proto_gre. Veel kaks tegelevad kõne identifikaatoriga, nf_conntrack_pptp ja nf_nat_pptp. Viimase laadimine tõmbab ülejäänud sõltuvuste kaudu sisse, seega peaks moodulite loend näitama kõiki nelja.

Vanemad juhised kasutavad 2.6 ajastu ip_ eesliidet. Need käsud võivad näida töötavat, samal ajal kui midagi ei laadita, seega kontrollige laaditud loendit, mitte väljumisstaatust.

Nende laaditud olemine ei ole enam piisav. Alates Linuxist 4.7 on sysctl net.netfilter.nf_conntrack_helper vaikimisi 0, mis lülitab uute voogude jaoks automaatse abilise määramise välja. Ruuteril võivad olla kõik moodulid ja see ei tõlgi ikkagi midagi. Kontrollige tegelikku väärtust enne, kui vaatate uuesti moodulite loendit.

Kas lülitage automaatne määramine globaalselt uuesti sisse, või kinnitage abiline voogudele, mis seda vajavad, ja jätke kõik muu rahule:

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

Teine valik on eelistatav. See piirab käitumise PPTP liiklusega, selle asemel et automaatset määramist kogu ruuteris uuesti lubada.

Protokolli avamine, millel pole porte

Tulemüürireegel, mis lubab 1723, ei ütle protokolli 47 kohta midagi. firewalld-is lubage protokoll tsoonis, mis on kliendi poole. Tavalises iptables-is võtke protokoll gre vastu sisendketis.

Seejärel püüdke mõlemal pool. Paketid, mis lahkuvad kliendist ilma saabuvate vastusteta, tähendavad, et tagasitee on filtreeritud, ja see on teine viga kui tagasilükatud volitus.

Pärast ühendumist suuruse piir

GRE lisab päise ja PPP selle sees lisab veel, seega töötav link teatab MTU-st, mis on tublisti alla 1500. Väikesed vastused laaditakse ja suured takerduvad, mis näeb välja nagu teine, mitteseotud probleem, mis ilmub hetkel, mil esimene on lahendatud.

Lugege MTU kliendi PPP-adapteril ja viige see kooskõlla ruuteri enda arvutusega selle asemel et numbreid langetada, kuni midagi tööle hakkab. Täissuuruses paketid, mis väljuvad ilma et midagi tagasi tuleks, osutavad sellele piirile, mitte tõlkimisele.

Tee parandamine paneb kasutaja tööle ja ei tee PPTP-st head valikut. MS-CHAPv2 ja RC4 on ammu vananenud, seega käsitlege mooduli laadimist ajutise parandusena ja planeerige üleminek hooldatud protokollile.