PPTP izveido savienojumu un pēc tam iekaras aiz Linux NAT: GRE palīgs

Kāds pārsūta 1723, klients sasniedz serveri, sākas autentifikācija, un tad viss apstājas bez kļūdas. Dabiskais secinājums ir nepareiza parole, tāpēc parole tiek ievadīta vēl trīs reizes. Pārsūtīšana bija kārtībā, un akreditācijas dati bija kārtībā. Salūza otrs protokols, kuru pārsūtīšana nekad neaptvēra, un kodola noklusējuma vērtība, kas klusi pārstāja tam palīdzēt.

Pārsūtīšana nekad nebija problēma

Porta pārsūtīšanas noteikums apraksta TCP vai UDP datu plūsmu. Tas nevar aprakstīt kravu, kas sesijas vidū pāriet uz citu IP protokolu, un PPTP dara tieši to.

Tāpēc savienojums izskatās vesels līdz brīdim, kad tas iekaras. Daļa, ko porta noteikums var pārvaldīt, izdevās, un daļa, ko tas nevar pārvaldīt, ir tā daļa, kas neizdevās.

TCP vadībai, GRE datiem

Zvans tiek saskaņots pa TCP 1723. Kad tas ir uzcelts, krava pāriet GRE, IP 47 protokolā, kas vispār nenes portu numurus. Noteikumam, kas balstās uz portiem, nav ar ko salīdzināt.

Tas, ko GRE nes, ir zvana identifikators tā galvenē, un NAT tulkotājam šis lauks ir konsekventi jāpārraksta abos virzienos, citādi abas sesijas puses pārstāj vienoties. Viens virziens pārrakstīts, otrs ne, rada sesiju, kas autentificējas un pēc tam izmet katru datu paketi. Tieši tāda ir simptoma forma: panākumi, tad klusums.

Kails GRE bez PPTP neprasa šādu pārrakstīšanu, tāpēc vienkāršs GRE tunelis var darboties caur maršrutētāju, kas tajā pašā ceļā neizdodas PPTP klientam.

Četri moduļi un sysctl, kas tos izslēdza

Divi moduļi apstrādā iekadrējumu, nf_conntrack_proto_gre un nf_nat_proto_gre. Vēl divi apstrādā zvana identifikatoru, nf_conntrack_pptp un nf_nat_pptp. Pēdējā ielāde caur atkarībām pievelk pārējos, tāpēc moduļu sarakstā jābūt redzamiem visiem četriem.

Vecākās instrukcijas izmanto 2.6 ēras ip_ prefiksu. Šīs komandas var izskatīties kā izpildās, kamēr nekas netiek ielādēts, tāpēc pārbaudiet ielādēto sarakstu, nevis iziešanas statusu.

Ar to ielādēšanu vairs nepietiek. Kopš Linux 4.7 sysctl net.netfilter.nf_conntrack_helper pēc noklusējuma ir 0, kas izslēdz automātisku palīga piešķiršanu jaunām plūsmām. Maršrutētājam var būt visi moduļi un tomēr nekas netiek tulkots. Pārbaudiet faktisko vērtību, pirms vēlreiz skatāties moduļu sarakstu.

Vai nu atkal ieslēdziet automātisko piešķiršanu visur, vai pievienojiet palīgu tām plūsmām, kurām tas nepieciešams, un atstājiet visu pārējo mierā:

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

Otrais variants ir vēlamais. Tas ierobežo uzvedību ar PPTP datu plūsmu, nevis atkal iespējo automātisko piešķiršanu visā maršrutētājā.

Protokola, kuram nav portu, atvēršana

Ugunsmūra noteikums, kas atļauj 1723, neko nepasaka par protokolu 47. Firewalld gadījumā atļaujiet protokolu zonā, kas vērsta pret klientu. Vienkāršā iptables gadījumā pieņemiet gre protokolu ievades ķēdē.

Pēc tam tveriet abās pusēs. Paketes, kas iziet no klienta bez ienākošām atbildēm, nozīmē, ka atgriešanās ceļš tiek filtrēts, un tā ir cita kļūme nekā noraidīti akreditācijas dati.

Pēc savienojuma izveides – izmēra ierobežojums

GRE ievieto galveni, un PPP tajā pievieno vēl, tāpēc strādājoša saite ziņo par MTU, kas ir krietni zem 1500. Mazas atbildes ielādējas, bet lielas iekaras, un tas izskatās kā otra, nesaistīta problēma, kas parādās tajā brīdī, kad pirmā ir atrisināta.

Nolasiet MTU klienta PPP adapterī un saskaņojiet to ar paša maršrutētāja aprēķinu tā vietā, lai pazeminātu skaitļus, līdz kaut kas sāk strādāt. Pilna izmēra paketes, kas iziet bez kaut kā atgriešanās, norāda uz šo ierobežojumu, nevis uz tulkošanu.

Ceļa labošana atgriež lietotāju darbā, un tas nepadara PPTP par labu izvēli. MS-CHAPv2 un RC4 sen jau ir novecojuši, tāpēc uzskatiet moduļu ielādi par pagaidu labojumu un plānojiet pāreju uz uzturētu protokolu.