PPTP konektiĝas kaj poste pendas malantaŭ Linux NAT: la GRE-helpilo

Iu plusendas 1723, la kliento atingas la servilon, aŭtentikigo komenciĝas, kaj tiam ĉio haltas sen eraro. La natura konkludo estas malĝusta pasvorto, do la pasvorto estas retajpita tri fojojn. La plusendo estis en ordo kaj la akreditiloj estis en ordo. Tio, kio rompiĝis, estas dua protokolo, kiun la plusendo neniam kovris, kaj kerna defaŭlto, kiu kviete ĉesis helpi pri ĝi.

La plusendo neniam estis la problemo

Regulo pri porda plusendo priskribas TCP aŭ UDP-trafikon. Ĝi ne povas priskribi utilan ŝarĝon, kiu mezvoje de seanco transiras al alia IP-protokolo, kaj PPTP faras ĝuste tion.

Tial la konekto aspektas sana ĝis la momento, kiam ĝi pendas. La parto, kiun porda regulo povas regi, sukcesis, kaj la parto, kiun ĝi ne povas regi, estas la parto, kiu fiaskis.

TCP por regado, GRE por datumoj

La alvoko estas intertraktata super TCP 1723. Post kiam ĝi staras, la utila ŝarĝo moviĝas en GRE, IP-protokolo 47, kiu tute ne portas pordnumerojn. Regulo, kiu baziĝas sur pordoj, havas nenion por kongruigi.

Tio, kion GRE portas, estas alvoka identigilo en sia kaploko, kaj NAT-tradukilo devas reskribi tiun kampon konsekvence en ambaŭ direktoj, alie la du duonoj de la seanco ĉesas interkonsenti unu kun la alia. Unu direkto reskribita kaj la alia ne produktas seancon, kiu aŭtentikigas kaj poste forĵetas ĉiun datumpaketon. Ĝuste tia estas la formo de la simptomo: sukceso, poste silento.

Nuda GRE sen PPTP bezonas neniun tian reskribon, tial ordinara GRE-tunelo povas funkcii tra enkursigilo, kiu fiaskas por PPTP-kliento sur la sama vojo.

Kvar moduloj kaj sysctl, kiu malŝaltis ilin

Du moduloj pritraktas la kadrigon, nf_conntrack_proto_gre kaj nf_nat_proto_gre. Du pliaj pritraktas la alvokan identigilon, nf_conntrack_pptp kaj nf_nat_pptp. Ŝargi la lastan el tiuj tiras la ceterajn per dependecoj, do modullisto devus montri ĉiujn kvar.

Pli malnovaj instrukcioj uzas antaŭfiksaĵon ip_ el la 2.6-epoko. Tiuj komandoj povas ŝajni funkcii dum ili ŝargas nenion, do kontrolu la ŝargitan liston anstataŭ la elirkodon.

Ŝargi ilin jam ne sufiĉas. Ekde Linux 4.7 la sysctl net.netfilter.nf_conntrack_helper defaŭltas al 0, kio malŝaltas aŭtomatan helpilan asignadon por novaj fluoj. Enkursigilo povas havi ĉiun modulon kaj tamen traduki nenion. Kontrolu la efektivan valoron antaŭ ol rigardi la modulliston denove.

Aŭ reŝaltu aŭtomatan asignadon tutmonde, aŭ alligu la helpilon al la fluoj, kiuj bezonas ĝin, kaj lasu ĉion alian trankvile:

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

La dua opcio estas la preferinda. Ĝi limigas la konduton al PPTP-trafiko anstataŭ reŝalti aŭtomatan asignadon tra la tuta enkursigilo.

Malfermi protokolon, kiu havas neniujn pordojn

Fajromura regulo, kiu permesas 1723, diras nenion pri protokolo 47. En firewalld permesu la protokolon en la zono frontanta al la kliento. En ordinara iptables akceptu la protokolon gre en la enira ĉeno.

Poste kaptu sur ambaŭ flankoj. Paketoj, kiuj forlasas la klienton sen alvenantaj respondoj, signifas ke la revena vojo estas filtrita, kaj tio estas alia fuŝo ol rifuzita akreditilo.

Post kiam ĝi konektiĝas, la grandolimo

GRE enmetas kaplokon, kaj PPP interne aldonas pli, do funkcianta ligilo raportas MTU konsiderinde sub 1500. Malgrandaj respondoj ŝargiĝas kaj grandaj haltas, kio aspektas kiel dua, nerilata problemo aperanta en la momento, kiam la unua solviĝas.

Legu la MTU en la PPP-adaptilo de la kliento kaj harmonigu ĝin kun la propra kalkulo de la enkursigilo anstataŭ malaltigi la nombrojn ĝis io funkcios. Plengrandaj paketoj elirantaj sen io revenanta montras al tiu limo kaj ne al la traduko.

Ripari la vojon funkciigas la uzanton, kaj ĝi ne faras PPTP bonan elekton. MS-CHAPv2 kaj RC4 estas delonge eksmodaj, do traktu la modulŝargon kiel provizoran riparon kaj planu transiron al prizorgata protokolo.