PPTP lidhet dhe më pas ngec pas Linux NAT: ndihmësi GRE
TCP 1723 lidhet dhe rruga e të dhënave vdes: PPTP udhëton në GRE, i cili nuk ka porta. Ngarkoni ndihmësit, lidhini ata në mënyrë eksplicite dhe hapni protokollin 47.
Dikush përcjell 1723, klienti arrin serverin, fillon vërtetimi dhe më pas gjithçka ndalon pa gabim. Përfundimi i natyrshëm është një fjalëkalim i gabuar, kështu që fjalëkalimi shtypet përsëri tre herë. Përcjellja ishte në rregull dhe kredencialet ishin në rregull. Ajo që u prish është një protokoll i dytë që përcjellja nuk e mbuloi kurrë, dhe një vlerë e paracaktuar e kernelit që ndaloi në heshtje së ndihmuari me të.
Përcjellja nuk ishte kurrë problemi
Një rregull përcjelljeje porte përshkruan trafikun TCP ose UDP. Ai nuk mund të përshkruajë një ngarkesë që kalon në një protokoll tjetër IP në mes të një sesioni, dhe PPTP bën pikërisht këtë.
Kjo është arsyeja pse lidhja duket e shëndetshme deri në momentin kur ngec. Pjesa që një rregull porte mund të qeverisë pati sukses, dhe pjesa që nuk mund të qeverisë është pjesa që dështoi.
TCP për kontroll, GRE për të dhëna
Thirrja negociohet përmes TCP 1723. Pasi ngrihet, ngarkesa kalon në GRE, protokolli IP 47, i cili nuk mbart fare numra portesh. Një rregull që mbështetet te portat nuk ka me çfarë të përputhet.
Ajo që GRE mbart është një identifikues thirrjeje në kryet e tij, dhe përkthyesi NAT duhet ta rishkruajë atë fushë në mënyrë konsistente në të dy drejtimet, përndryshe dy gjysmat e sesionit ndalojnë së qeni dakord. Një drejtim i rishkruar dhe tjetri jo prodhon një sesion që vërteton dhe më pas hedh çdo paketë të dhënash. Kjo është saktësisht forma e simptomës: sukses, pastaj heshtje.
GRE i zhveshur pa PPTP nuk kërkon një rishkrim të tillë, prandaj një tunel GRE i thjeshtë mund të funksionojë përmes një ruteri që dështon për një klient PPTP në të njëjtën rrugë.
Katër module dhe një sysctl që i fiku
Dy module merren me kornizimin, nf_conntrack_proto_gre dhe nf_nat_proto_gre. Dy të tjerë merren me identifikuesin e thirrjes, nf_conntrack_pptp dhe nf_nat_pptp. Ngarkimi i të fundit tërheq të tjerët përmes varësive, kështu që lista e moduleve duhet të tregojë të katërt.
Udhëzimet më të vjetra përdorin një parashtesë ip_ nga epoka 2.6. Ato komanda mund të duken sikur ekzekutohen pa ngarkuar asgjë, prandaj kontrolloni listën e ngarkuar në vend të statusit të daljes.
T'i kesh të ngarkuar nuk mjafton më. Që nga Linux 4.7 sysctl net.netfilter.nf_conntrack_helper është 0 si parazgjedhje, gjë që çaktivizon caktimin automatik të ndihmësit për rrjedhat e reja. Një ruter mund të ketë çdo modul dhe prapë të mos përkthejë asgjë. Kontrolloni vlerën efektive përpara se të shikoni përsëri listën e moduleve.
Ose riaktivizoni caktimin automatik globalisht, ose lidhni ndihmësin me rrjedhat që kanë nevojë për të dhe lini gjithçka tjetër në paqe:
iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptpOpsioni i dytë është ai i preferueshëm. Ai e kufizon sjelljen te trafiku PPTP në vend që të riaktivizojë caktimin automatik në të gjithë ruterin.
Hapja e një protokolli që nuk ka porta
Një rregull muri zjarri që lejon 1723 nuk thotë asgjë për protokollin 47. Në firewalld, lejoni protokollin në zonën që shikon nga klienti. Në iptables të thjeshtë, pranoni protokollin gre në zinxhirin e hyrjes.
Pastaj kapni në të dyja anët. Paketat që largohen nga klienti pa ardhur përgjigje do të thotë se rruga e kthimit është filtruar, dhe ky është një defekt tjetër nga një kredencial i refuzuar.
Pasi lidhet, kufiri i madhësisë
GRE fut një krye, dhe PPP brenda tij shton më shumë, kështu që një lidhje funksionale raporton një MTU shumë nën 1500. Përgjigjet e vogla ngarkohen dhe ato të mëdha ngecin, gjë që duket si një problem i dytë i palidhur që shfaqet në momentin kur zgjidhet i pari.
Lexoni MTU-në në përshtatësin PPP të klientit dhe pajtojeni atë me llogaritjen e vetë ruterit në vend që të ulni numrat derisa diçka të funksionojë. Paketat me madhësi të plotë që dalin pa u kthyer asgjë tregojnë për atë kufi dhe jo për përkthimin.
Rregullimi i rrugës e kthen përdoruesin në punë, dhe kjo nuk e bën PPTP një zgjedhje të mirë. MS-CHAPv2 dhe RC4 janë vjetëruar prej kohësh, prandaj trajtojeni ngarkimin e moduleve si një rregullim të përkohshëm dhe planifikoni kalimin në një protokoll të mirëmbajtur.