Kwa nini PPTP na L2TP/IPsec husimama kabla ya ombi la jina la mtumiaji?

Kutokuwa na ombi la jina la mtumiaji ni zawadi ya utambuzi: PPP bado haijaanza, kwa hivyo akaunti, nenosiri na sera ya kikoa bado hazijaulizwa. Katika muunganisho wa PPTP au L2TP/IPsec mteja huomba vitambulisho tu baada ya handaki kuwepo na seva kuanza kipindi cha PPP. Kila kitu kinachoweza kushindwa kabla ya wakati huo ni usafirishaji, ubadilishanaji wa funguo au usanidi wa handaki, eneo dogo zaidi kuliko «VPN imeharibika».

Ombi lisilopo hupunguza hitilafu hadi hatua tatu

Andika hatua ya mwisho iliyofanikiwa kwa kuonekana, kwa sababu kila moja ina mmiliki na suluhisho tofauti. Kukisia mipangilio ya akaunti ukiwa umekwama hatua mbili mapema ndiyo njia ambayo mchana hupotea.

Mteja anayeisha muda bila ombi hakuwahi kupata muungano wa IPsec, kwa hivyo hitilafu iko katika IKE au katika ikiwa pakiti zako zinafika kwenye lango. Yule anayeripoti kuwa anathibitisha vitambulisho kisha huanguka alifika mbali zaidi kuliko ujumbe unavyodokeza. Ombi linalofuatwa na kukataliwa ni uthibitishaji wa PPP, na hilo ni la makala ya akaunti, si hii.

Hatua ya kwanza: itifaki ambayo ukuta wa moto huiacha kimya

PPTP inahitaji TCP 1723 kwa njia yake ya udhibiti na itifaki ya IP 47 kwa njia ya data, na hizo mbili husafiri tofauti. Mitandao mingi hupitisha 1723 na kuacha itifaki 47, jambo ambalo huunda handaki linalojadiliana kisha halibeba kitu chochote. Kipanga njia kinachofanya NAT pia kinahitaji kifungu kinachoauni GRE, na njia ya ufikiaji ya IPv6 pekee haiwezi kubeba PPTP katika usanidi wowote.

L2TP juu ya IPsec hutumia mlango 500 kwa IKE na mlango 4500 kwa kuvuka NAT, kisha hufunga trafiki ya L2TP yenyewe ndani ya 1701, huku ESP ikibeba mzigo uliolindwa pindi muungano unapokuwepo. Ruhusu milango miwili ya udhibiti lakini si ESP, na utapata dalili halisi ya kichwa: maendeleo yanayoonekana, kisha mteja aliyekufa kabla ya mazungumzo yoyote ya vitambulisho. Kujaribu kutoka hotspot ya simu ni njia nafuu ya kutenganisha tatizo la mteja na tatizo la njia.

Hatua ya pili: ufunguo ambao si ufunguo, pendekezo ambalo halitolewi

Ufunguo ulioshirikiwa mapema ambao haulingani hushindwa haraka na kimya, na toleo la kawaida ni ufunguo unaoonekana sahihi kwenye skrini lakini unabeba mwendo wa mstari uliobandikwa au nafasi mwishoni. Kwenye mteja wa Linux mazungumzo si lazima yawe chanzo cha ukweli: programu jalizi ya L2TP ya NetworkManager huhifadhi siri katika faili chini ya /etc/ipsec.d/, na faili ya zamani kwa kila muunganisho ambayo /etc/ipsec.secrets bado inaijumuisha itatumika badala ya ile uliyoandika hivi punde. Nakili faili hiyo mahali salama, iondoe kwenye njia ya ujumuishaji, kisha andika ufunguo tena kwa mkono.

Nusu nyingine ya hatua hii ni pendekezo. Pande zote mbili lazima zikubaliane juu ya seti moja ya algoriti ya awamu ya 1 — usimbaji fiche, uadilifu na kikundi cha Diffie-Hellman — na mabadiliko ya ESP yanayolingana kwa awamu ya 2, vinginevyo muungano haufanyiki kabisa. Lango linalotoa 3DES, SHA1 na MODP1024 pekee litakataa mteja aliyesanidiwa kwa algoriti zenye nguvu zaidi, na kumbukumbu yake hutaja mabadiliko yaliyokataliwa. Kumbukumbu hutaja kutolingana ikiwa utaisoma badala ya kuwasha tena huduma. Badala ya kunakili mnyororo wa algoriti kutoka uzi wa jukwaa, muulize lango ni mabadiliko gani itakayojadiliana kwa kweli: ike-scan inayoelekezwa kwenye anwani yake hurudisha mabadiliko ambayo itayajadiliana. Ikiwa toleo pekee ni usimbaji fiche ambao sera yako hairuhusu tena, marekebisho ni ya lango, si ya kushusha mteja.

Katika Windows ufunguo na njia ya uthibitishaji hukaa kwenye wasifu wa VPN, na kutolingana huonekana kabla ya ombi la vitambulisho badala ya baada yake. Pale mpokeaji ni Windows Server, thibitisha kuwa jukumu la ufikiaji wa mbali limesakinishwa, kwamba cheti kinalingana na jina ambalo wateja huunganisha nalo, na kwamba hakuna kichujio cha mlango kilicho chembamba kuliko itifaki zilizo juu.

Hatua ya tatu: handaki lipo na PPP haianzi

IKE inapokamilika na ombi bado halionekani, angalia daemon ya handaki badala ya ukuta wa moto. L2TP inahitaji kitu kinachosikiliza kwenye UDP 1701 — xl2tpd au kl2tpd kwenye Linux, huduma ya ufikiaji wa mbali kwenye Windows — na huduma iliyosakinishwa lakini imesimamishwa huonekana kutoka upande wa mteja sawa kabisa na pakiti iliyotupwa. Angalia msikilizaji kabla ya kufungua tena sheria ambazo tayari umezithibitisha. Kisha PPP lazima ijadiliane, na ubadilishanaji wa kwanza wa LCP ndipo mahali ambapo kushindwa kimya huteremka.

Mtego mmoja katika hatua hii si hitilafu ya mtandao hata kidogo: Windows huruhusu muunganisho mmoja wa aina fulani ya VPN kwa wakati mmoja, kwa hivyo jaribio la pili hurudisha kosa 937, «muunganisho mwingine wa aina hii unatumika». Hiyo ni sheria ya ndani, na njia ya kuipita ni kifaa kingine, aina nyingine ya handaki, au kushiriki muunganisho mmoja uliopo tayari.

Soma kumbukumbu kwa mpangilio wa hatua badala ya kukisia

Simamisha mteja, ianzishe tena, na soma vipengele kwa mpangilio vinavyoandika kumbukumbu. Yaani kwanza daemon ya IPsec — strongSwan au Libreswan, na ipsec --version inakuambia ipi — kisha daemon ya L2TP, kisha pppd. Kipengele chochote kilichoandika mwisho kabla ya kushindwa ndicho kinachoonyesha hatua ya kuchunguza, kwa sababu kila kitu kinachofuata kwenye mfuatano hakikufanya kazi kabisa.

Thibitisha kwa muunganisho mpya na si kipindi kilichohifadhiwa, kwa sababu mteja anayeunganisha tena kutoka akiba anaweza kuruka sehemu za ubadilishanaji na kuzalisha matokeo ya zamani. Thibitisha ufikiaji, ubadilishanaji wa funguo, handaki na PPP moja baada ya nyingine, kwa mpangilio huo. Hapo ombi lisilopo huacha kuwa fumbo na huwa mstari wa pili wa orodha ambayo kwa kweli unaweza kuifanyia kazi. Orodha hiyo pia ni ile unayokabidhi kwa timu ya mtandao, ambao vinginevyo wangeombwa kuangalia ukuta wa moto kwa hitilafu inayoishi katika daemon isiyoanzishwa.