L2TP/IPsec inashindwa: tenga IPsec, uthibitishaji wa handaki au kuingia PPP

Mambo matatu hujithibitisha ndani ya muunganisho mmoja wa L2TP/IPsec, na ni moja tu kati yao linalomhusisha mtu anayepiga simu. IPsec huthibitisha ncha za handaki, muunganisho wa udhibiti wa L2TP unaweza kuthibitisha tena wenzake kwa siri yake yenyewe, kisha PPP huthibitisha akaunti ya mtumiaji ndani ya kipindi. Kushindwa katika hatua yoyote huonekana kama hitilafu ya jumla ya kuingia kwenye mazungumzo ya mteja na huonekana tofauti kabisa kwenye kumbukumbu za seva. Pitia hatua kwa mpangilio na simama kwenye ya kwanza inayoshindwa, kwa sababu kila hatua chini ya hatua isiyojaribiwa pia haijajaribiwa.

Hatua tatu za uthibitishaji, vitambulisho vitatu tofauti

IPsec huthibitisha nani anamiliki ncha, kwa kutumia ufunguo ulioshirikiwa mapema au cheti. Utambulisho huo ni wa mashine au lango, kamwe si wa mtu aliye mbele ya kibodi. Wenzake wanaposhindwa kukubaliana katika hatua hii, hakuna pakiti yoyote ya L2TP inayobadilishana.

Muunganisho wa udhibiti wa L2TP unaweza kuongeza ubadilishanaji wa pili, tofauti wa changamoto-jibu, unaoongozwa na siri ya pamoja ambayo ncha zote mbili lazima ziwe nayo.

RFC 2661 hufanya uthibitishaji huo wa muunganisho wa udhibiti kuwa wa hiari, jambo ambalo hufafanua kwa nini kosa lile lile hutoa dalili tofauti kwenye seva mbili. Usambazaji ambao haukuweka siri ya handaki hukosa hatua kabisa; ule uliyoweka upande mmoja tu hushindwa kabla PPP haijatolewa. Kisha PPP huthibitisha mtumiaji kwa PAP, CHAP au MSCHAPv2 na kupeana jina kwa hazina ya akaunti ambayo inaweza kuwa ya ndani, ndani ya chap-secrets au kwenye RADIUS. Nenosiri lisilo sahihi wakati huo bado linakuacha na handaki inayofanya kazi na kipindi kilichoshindwa.

Soma mahali pa kusimama kabla ya kuhariri usanidi

Anza na ipsec --version ili ujue kama matokeo ya hali ni ya strongSwan au Libreswan. Kisha soma kumbukumbu za seva, si mazungumzo ya mteja, kwa sababu seva hurekodi ni hatua gani ilikataa.

Mstari mmoja kwa kawaida hutatua tiketi: malalamiko ya IKE au mapendekezo ni hatua ya kwanza, ujumbe wa muunganisho wa udhibiti ni hatua ya pili, na kukataa kwa njia ya PPP au akaunti ni hatua ya tatu. Nakili mstari huo kwenye tiketi pamoja na muhuri wa muda. Kukisia kutoka upande wa mteja hupoteza ushahidi pekee ambao tayari unayo.

Weka nyenzo za ufunguo na nenosiri nje ya ubadilishanaji huo; jina la hatua huelekeza kazi, na ufunguo ulioshirikiwa mapema uliovuja hufungua tena tiketi kwa matokeo mabaya zaidi.

Hatua ya kwanza: IPsec ina muungano?

Endesha ipsec statusall kwenye strongSwan au ipsec whack --status kwenye Libreswan na utafute muungano wa mtoto ulioimarishwa wenye vihesabu visivyo sifuri. ip xfrm state huonyesha mwonekano wa kerneli kwa zote mbili. Jozi ya SA iliyosakinishwa na vihesabu vinavyopanda inamaanisha hatua ya kwanza imekamilika na unaweza kuendelea.

Kutokuwepo kabisa kwa muungano kunaonyesha anwani ya mwenza, seti ya mapendekezo au ufunguo ulioshirikiwa mapema, na mara kwa mara kifaa kinachoandika upya UDP 500 huku kikitupa UDP 4500. Muungano unaoimarika kisha kutoweka baada ya sekunde chache kwa kawaida ni kutokulingana kwa muda wa maisha kati ya ncha mbili na si tatizo la vitambulisho. Angalia kama pande zote zinataja mapendekezo sawa ya usimbaji na hashi kabla ya kuandika kitu tena. Ikiwa sivyo, hakuna ufunguo utakaofanya kazi kamwe.

Simama wakati muungano haupo. Kuhariri chaguo za PPP wakati huo hakubadilishi chochote na huficha hitilafu halisi kwa mtu anayefuata.

Hatua ya pili: muunganisho wa udhibiti wa L2TP ulijithibitisha?

Mara IPsec inapoinuka, angalia daemon ya L2TP kwa muunganisho wa udhibiti unaofikia hali iliyoimarishwa, kwa kuwa PPP haiwezi kuanza kabla ya hapo. Kukataa kwenye muunganisho wa udhibiti kunamaanisha siri ya handaki inatofautiana kati ya ncha, au ncha moja inadai siri ambayo nyingine haitumi kamwe. Wateja mara nyingi huonyesha sehemu moja yenye lebo shared secret, na kwa kawaida ni ya IPsec na si L2TP. Kuijaza hakusanidi siri ya handaki, na kuifuta hakuzima.

Ikiwa hakuna upande uliosanidi siri ya handaki, ruka hatua hii na uchukulie kushindwa kwa muunganisho wa udhibiti kama tatizo la ufikikaji. Thibitisha kwamba UDP 1701 inafikia daemon na kwamba ncha zote mbili zinakubaliana juu ya usimbaji mmoja. Sheria ya ukuta wa moto iliyoandikwa kwa moja ya masharti hayo mawili ni sababu ya kawaida ya muunganisho unaofunguka nusu.

Ni kipindi kinachoanza kujadili PPP pekee kilichopita hatua ya handaki kwa kweli.

Hatua ya tatu: PPP inakataa akaunti?

Kushindwa kwa PPP huonekana tofauti kutoka nje: handaki imeimarishwa, kipindi kinaanza, na daemon hurekodi kushindwa kwa njia ya uthibitishaji au kukataa akaunti. Soma njia iliyotajwa katika ujumbe huo. PAP na CHAP hushindwa kwa sababu tofauti, na seva inayokataa moja itamkataa mteja anayetoa hiyo pekee.

Kwenye seva ya Linux, chunguza faili ya chaguo ambayo daemon inaipa PPP, kwa kawaida /etc/ppp/options.xl2tpd, na uthibitisha ni njia zipi zinazokubaliwa na wapi akaunti hutatuliwa. Jina lililopo RADIUS lakini halipo kwenye faili ya siri ya ndani hushindwa kwa usafi na huonekana kama nenosiri lisilo sahihi. Kisha angalia kwamba mteja anatoa njia ambayo seva inakubali, si yenye nguvu zaidi ambayo seva inakataa kujadili. Kubadilisha ufunguo ulioshirikiwa mapema ili kurekebisha hatua hii hupoteza mchana na hakubadilishi chochote.

Kipindi kinapoinuka hatimaye, ugawaji wa anwani, DNS na njia bado hazijakaguliwa, na kila kimoja hushindwa kimya kwa njia yake. Weka tabaka tatu tofauti katika maelezo yako: ufunguo sahihi na akaunti isiyo sahihi hushindwa kila wakati, na kurekebisha tabaka moja hakurekebishi lingine kamwe.