PPTP prisijungia, o paskui užstringa už Linux NAT: GRE pagalbininkas

Kažkas peradresuoja 1723, klientas pasiekia serverį, prasideda autentifikavimas, o tada viskas sustoja be klaidos. Natūrali išvada – neteisingas slaptažodis, todėl slaptažodis įvedamas dar tris kartus. Peradresavimas buvo tvarkingas ir prisijungimo duomenys buvo tvarkingi. Suiro antrasis protokolas, kurio peradresavimas niekada neapėmė, ir branduolio numatytoji reikšmė, kuri tyliai nustojo tam padėti.

Peradresavimas niekada nebuvo problema

Prievado peradresavimo taisyklė aprašo TCP arba UDP srautą. Ji negali aprašyti turinio, kuris sesijos viduryje pereina prie kito IP protokolo, o PPTP daro būtent tai.

Štai kodėl ryšys atrodo sveikas iki tos akimirkos, kai užstringa. Dalis, kurią prievado taisyklė gali valdyti, pavyko, o dalis, kurios ji negali valdyti, yra ta dalis, kuri nepavyko.

TCP valdymui, GRE duomenims

Skambutis derinamas per TCP 1723. Kai jis pakyla, turinys persikelia į GRE, IP protokolą 47, kuris visiškai netransportuoja prievadų numerių. Taisyklė, kuri remiasi prievadais, neturi ko palyginti.

Tai, ką GRE neša, yra skambučio identifikatorius jo antraštėje, o NAT vertėjas turi perrašyti tą lauką nuosekliai abiem kryptimis, kitaip dvi sesijos pusės nustoja susitarti. Viena kryptis perrašyta, o kita ne, sukuria sesiją, kuri autentifikuojasi ir tada išmeta kiekvieną duomenų paketą. Būtent tokia yra simptomo forma: sėkmė, paskui tyla.

Plikas GRE be PPTP nereikalauja tokio perrašymo, todėl paprastas GRE tunelis gali veikti per maršrutizatorių, kuris tame pačiame kelyje nepavyksta PPTP klientui.

Keturi moduliai ir sysctl, kuris juos išjungė

Du moduliai tvarko įrėminimą, nf_conntrack_proto_gre ir nf_nat_proto_gre. Dar du tvarko skambučio identifikatorių, nf_conntrack_pptp ir nf_nat_pptp. Paskutiniojo įkėlimas per priklausomybes įtraukia kitus, todėl modulių sąraše turėtų būti visi keturi.

Senesnės instrukcijos naudoja 2.6 eros ip_ priešdėlį. Tos komandos gali atrodyti veikiančios, nors nieko neįkelia, todėl tikrinkite įkeltą sąrašą, o ne išėjimo būseną.

Jų įkelti nebepakanka. Nuo Linux 4.7 sysctl net.netfilter.nf_conntrack_helper pagal numatytuosius nustatymus yra 0, o tai išjungia automatinį pagalbininko priskyrimą naujiems srautams. Maršrutizatorius gali turėti visus modulius ir vis tiek nieko neversti. Prieš vėl žiūrėdami į modulių sąrašą, patikrinkite faktinę reikšmę.

Arba vėl įjunkite automatinį priskyrimą visur, arba prijunkite pagalbininką prie srautų, kuriems jo reikia, ir palikite visa kita ramybėje:

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

Antrasis variantas yra geresnis. Jis apriboja elgesį PPTP srautu, o ne vėl įjungia automatinį priskyrimą visame maršrutizatoriuje.

Protokolo, kuris neturi prievadų, atidarymas

Užkardos taisyklė, leidžianti 1723, nieko nesako apie 47 protokolą. firewalld atveju leiskite protokolą zonoje, nukreiptoje į klientą. Paprasto iptables atveju priimkite gre protokolą įvesties grandinėje.

Tada fiksuokite abiejose pusėse. Paketai, išeinantys iš kliento be ateinančių atsakymų, reiškia, kad grįžimo kelias filtruojamas, ir tai yra kita gedimas nei atmesti prisijungimo duomenys.

Po prisijungimo – dydžio riba

GRE įterpia antraštę, o PPP joje prideda daugiau, todėl veikianti jungtis praneša apie MTU, gerokai mažesnį nei 1500. Maži atsakymai įkeliami, o dideli užstringa, ir tai atrodo kaip antra, nesusijusi problema, pasirodanti tą akimirką, kai pirmoji išspręsta.

Perskaitykite MTU kliento PPP adapteryje ir suderinkite jį su paties maršrutizatoriaus skaičiavimu užuot mažinę skaičius, kol kas nors pradės veikti. Viso dydžio paketai, išeinantys be nieko, kas grįžtų, rodo į tą ribą, o ne į vertimą.

Kelio taisymas grąžina naudotoją į darbą, ir tai nepadaro PPTP gero pasirinkimo. MS-CHAPv2 ir RC4 seniai pasenę, todėl modulių įkėlimą laikykite laikinu pataisymu ir planuokite perėjimą prie prižiūrimo protokolo.