PPTP tengist og hangir svo á bak við Linux NAT: GRE-hjálparinn

Einhver framsendir 1723, biðlarinn nær í þjóninn, auðkenning hefst og svo stöðvast allt án villu. Eðlileg ályktun er rangt lykilorð, svo lykilorðið er slegið inn þrisvar sinnum aftur. Framendingin var í lagi og skírteinin voru í lagi. Það sem bilaði er önnur samskiptaregla sem framendingin náði aldrei yfir, og sjálfgefið kjarnagildi sem hætti hljóðlega að hjálpa með henni.

Framendingin var aldrei vandamálið

Regla um hafnarframendingu lýsir TCP- eða UDP-umferð. Hún getur ekki lýst farmi sem skiptir yfir í aðra IP-samskiptareglu mitt í setu, og PPTP gerir einmitt það.

Þess vegna virðist tengingin heilbrigð allt að þeirri stundu sem hún hangir. Sá hluti sem hafnarregla getur stjórnað tókst, og sá hluti sem hún getur ekki stjórnað er sá hluti sem mistókst.

TCP fyrir stjórnun, GRE fyrir gögn

Kallið er samið um yfir TCP 1723. Þegar það er komið upp færist farmurinn inn í GRE, IP-samskiptareglu 47, sem ber engin hafnarnúmer yfirleitt. Regla sem byggir á höfnum hefur ekkert til að stemma við.

Það sem GRE ber er kallauðkenni í hausnum, og NAT-þýðandinn verður að endurskrifa þann reit á samkvæman hátt í báðar áttir eða tveir helmingar setunnar hætta að vera sammála. Ein átt endurskrifuð og hin ekki framleiðir setu sem auðkennir sig og hendir síðan hverju gagnapakka. Þetta er nákvæmlega lögun einkennisins: árangur, svo þögn.

Berið GRE án PPTP þarf enga slíka endurskrifun, þess vegna getur venjulegt GRE-göng virkað í gegnum beini sem bregst fyrir PPTP-biðlara á sömu leið.

Fjögur einingar og sysctl sem slökkti á þeim

Tvær einingar sjá um rammagjörðina, nf_conntrack_proto_gre og nf_nat_proto_gre. Tvær aðrar sjá um kallauðkennið, nf_conntrack_pptp og nf_nat_pptp. Að hlaða þeirri síðustu dregur hinar inn gegnum fylgni, svo einingalisti ætti að sýna allar fjórar.

Eldri leiðbeiningar nota ip_ forskeyti frá 2.6 tímabilinu. Þessar skipanir geta virst keyra án þess að hlaða neinu, svo athugið hlaðna listann frekar en útgangsstöðuna.

Að hafa þær hlaðnar er ekki nóg lengur. Frá Linux 4.7 er sjálfgefið gildi sysctl net.netfilter.nf_conntrack_helper 0, sem slekkur á sjálfvirkri úthlutun hjálpara fyrir nýjar straumar. Beini getur haft hverja einingu og þýðir samt ekkert. Athugið raunverulega gildið áður en þið lítið aftur á einingalistann.

Annaðhvort kveikið þið á sjálfvirkri úthlutun aftur á heimsvísu, eða tengið hjálparann við straumana sem þurfa hann og látið allt annað í friði:

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

Seinni valkosturinn er sá sem ætti að velja. Hann takmarkar hegðunina við PPTP-umferð í stað þess að endurkveikja sjálfvirka úthlutun um allan beininn.

Að opna samskiptareglu sem hefur engar hafnir

Eldveggjaregla sem leyfir 1723 segir ekkert um samskiptareglu 47. Í firewalld skuluð þið leyfa samskiptaregluna á svæðinu sem snýr að biðlaranum. Í venjulegu iptables skuluð þið samþykkja samskiptaregluna gre í inntakskeðjunni.

Nemið svo á báðum hliðum. Pakkar sem fara frá biðlaranum án þess að svör berist þýða að afturleiðin er sigtuð, og það er önnur bilun en hafnað skírteini.

Eftir að það tengist, stærðartakmörkin

GRE setur inn haus, og PPP inni í honum bætir við meiru, svo virk tenging tilkynnir MTU sem er vel undir 1500. Lítil svör hlaðast og stór stöðvast, sem lítur út sem annað, ótengt vandamál sem birtist um leið og það fyrsta er leyst.

Lestu MTU á PPP-adaptter biðlarans og samræmdu það við eigin útreikning beinisins í stað þess að lækka tölurnar þar til eitthvað virkar. Pakkar í fullri stærð sem fara út án þess að nokkuð komi til baka benda á þetta takmörk en ekki þýðinguna.

Að laga leiðina kemur notandanum í gang, og það gerir PPTP ekki að góðum valkosti. MS-CHAPv2 og RC4 hafa lengi verið úrelt, svo meðhöndlið hleðslu eininganna sem tímabundna lagfæringu og skipuleggið flutning yfir í samskiptareglu sem er viðhaldin.