PPTP ndani ya Docker huthibitisha lakini haibeba trafiki

Mteja huthibitisha, PPP hujadili anwani, kisha hakuna kinachosogea. Ping inashindikana, kivinjari kinashindikana, na kontena huonekana limeunganishwa muda wote. Mtindo huu si tatizo la jedwali la njia, kwa sababu matatizo ya njia kwa kawaida huvunja pia muunganisho wa udhibiti. Ni njia ya mzigo, na katika PPTP mzigo ni itifaki tofauti na ile iliyofanikiwa hivi punde.

Ukaguzi watano, kwa mpangilio unaookoa muda mwingi zaidi.

Ukaguzi 1: tenga chaneli ya udhibiti na mzigo

PPTP huthibitisha kupitia TCP 1723 kisha hubeba mzigo wa PPP ndani ya GRE, itifaki ya IP 47. GRE si TCP wala UDP, kwa hiyo kila kanuni inayopitisha bandari ya udhibiti haisemi chochote kuhusu hilo. NAT au ngome ya moto inayopitisha 1723 inaweza kudondosha itifaki 47 bila malalamiko, na kipindi kinabaki nusu-kujengwa kwa namna inayofanana na mafanikio.

Ikiwa kuingia kunafanya kazi na hakuna pakiti inayorudi, chukulia GRE kwanza kisha thibitisha hilo baadaye.

Ukaguzi 2: thibitisha msaidizi katika kerneli ya mwenyeji

Ufuatiliaji wa muunganisho hauwezi kuunganisha muunganisho wa udhibiti wa TCP na mtiririko wa GRE bila msaidizi. Moduli ni nf_conntrack_pptp, inaishi katika kerneli ya mwenyeji, na kuipakia ndani ya taswira ya kontena hakufanikishi chochote kwa sababu moduli zinatumika kwa mwenyeji mzima. lsmod | grep nf_conntrack_pptp kwenye mwenyeji wa Docker ndio ukaguzi. Ikiwa haipo, modprobe nf_conntrack_pptp huipakia kwa kerneli inayoendesha na haisemi chochote kuhusu kuwasha kunakofuata, kwa hiyo iongeze pia kwenye usanidi wa mwenyeji.

Moduli inayotoweka wakati wa kuwasha upya huwa tikiti ile ile mwezi ujao.

Ukaguzi 3: soma sera ya kerneli inayoizima

Hata moduli ikiwepo, kerneli tangu 4.7 huweka net.netfilter.nf_conntrack_helper kuwa 0 kwa chaguo-msingi, jambo ambalo huzima ugawaji wa kiotomatiki wa msaidizi kwa kila itifaki. Chaguo hilo ndilo sababu moduli iliyosakinishwa ipasavyo bado haifanyi chochote: msimbo upo na sera inasema usiitumie. sysctl net.netfilter.nf_conntrack_helper huripoti thamani ya sasa, na kuiweka kuwa 1 wakati wa uendeshaji humfanya msaidizi apatikane tena. Hifadhi thamani kupitia usanidi wa sysctl wa mwenyeji ikiwa muundo unaruhusu.

Ugawaji wa kiotomatiki huruhusu trafiki kuunda matarajio kwa njia isiyo ya moja kwa moja, na ndilo sababu chaguo-msingi lilibadilishwa. Iwekee kikomo kwa mwenyeji anayeaminika, au tumia kanuni iliyo wazi inayolenga msaidizi.

Ukaguzi 4: tazama njia ya kontena kwa namna tofauti

Msaidizi aliyepakiwa hauzi njia. Kontena linahitaji njia kuelekea seva ya PPTP, na upelekaji kwenye mwenyeji lazima uruhusu GRE pande zote mbili: iptables -L FORWARD -v -n unaonyesha ikiwa itifaki 47 inakubaliwa na ikiwa vihesabu vinatembea. Kanuni za masquerade za Docker hutafsiri TCP na UDP, si itifaki 47, kwa hiyo kontena lenye daraja linaweza kuhitaji kibali cha wazi cha forward na, kwenye baadhi ya wenyeji, kanuni yake ya utafsiri. Pia thibitisha kwamba kontena lina msaada wa kifaa cha PPP ambao taswira yake inatarajia.

Soma vihesabu badala ya maandishi ya kanuni. Kanuni iliyopo na isiyoendana na chochote ni mapambo.

Ukaguzi 5: thibitisha GRE inafuatiliwa, kisha amua kuhusu PPTP

Mteja akiwa anaendesha, soma jedwali la ufuatiliaji. Ingizo la udhibiti la PPTP lililoanzishwa pamoja na ingizo la GRE linalohusiana humaanisha kuwa msaidizi anaunganisha mitiririko na kasoro iliyobaki iko mahali pengine. Ingizo la udhibiti lisilo na ingizo la GRE humaanisha kuwa mzigo unadondoshwa au haufuatiliwi, jambo linalokurudisha kwenye ukaguzi 2 na 3.

PPTP yenyewe ni ya zamani na MS-CHAPv2 ni dhaifu. Ikiwa seva pia inatoa L2TP/IPsec, IKEv2 au WireGuard, kuhamia mojawapo ya hizo kunaondoa darasa hili lote la matatizo.

Mahali ambapo PPTP lazima ibaki, kuendesha mteja kwenye mwenyeji badala ya ndani ya kontena kunaondoa tabaka moja la NAT na uchujaji, ambayo mara nyingi ni uamuzi wa bei nafuu.