L2TP NO_PROPOSAL_CHOSEN: ni awamu ipi iliyoshindwa kwa kweli?

NO_PROPOSAL_CHOSEN huja kabla ya jina lolote la mtumiaji la PPP kuchunguzwa, jambo ambalo ni ukweli wenye faida na pia sababu ya ujumbe kupotosha. Inaripoti kwamba upande mmoja ulikataa pendekezo; hairipoti kigezo kipi hakikulingana, na haisemi chochote kuhusu ikiwa kukataa kulitokea wakati wa kujenga muungano wa IKE au baadaye wakati wa majadiliano ya ulinzi wa trafiki. Nyuma ya uwezekano huo mbili kuna marekebisho mawili tofauti, na moja tu kati yao linahusisha kisanduku cha tiki cha PFS ambacho watu hukikimbilia kwanza.

Ujumbe mmoja, seti mbili za mapendekezo

Mpangilio wa IKEv1 L2TP/IPsec una majadiliano mawili mfululizo. Awamu 1 hujenga muungano wa usalama wa IKE kutoka algoriti ya usimbaji fiche, algoriti ya uadilifu na kundi la Diffie-Hellman. Kisha awamu 2 hujadili jinsi trafiki italindwa, na sharti la PFS ni la mazungumzo hayo ya pili.

Kwa kuwa awamu zinafuata, mahali pa kushindwa hukuambia orodha ipi ya kulinganisha. Hapo ndipo thamani yote ya uchunguzi ya ujumbe ilipo, na inafaa kuichukua kabla ya kugusa mpangilio wowote.

Kwa nini kisanduku cha PFS hakiwezi kurekebisha awamu 1

Kuzima PFS hubadilisha sifa ya awamu 2. Ikiwa pande hazikuwahi kukubaliana kuhusu awamu 1, mazungumzo ya ESP hayatokei kabisa, kwa hivyo kisanduku hakina athari yoyote kwenye kukataa, na ndiyo sababu kubadilisha kwake hutoa hitilafu hiyo hiyo na muhuri wa muda tofauti.

Hitilafu ya kinyume ni ya kawaida vile vile. Muungano wa IKE uliofanikiwa hauthibitishi kwamba pendekezo la ESP linakubalika, na kwa hakika hauthibitishi kwamba kundi la awamu 2 linalingana. Chukua handaki ya usimamizi iliyoanzishwa kama ushahidi kuhusu awamu 1 pekee. Watu husoma mstari wa kijani kama «handaki inafanya kazi», kisha hutumia saa moja kwenye awamu isiyo sahihi kwa sababu hakuna kilichowaambia kwamba majadiliano ya pili hayakuanza.

Soma kumbukumbu kabla ya kuchagua algoriti

Kusanya ujumbe uliotangulia kukataa moja kwa moja kutoka backend inayoshughulikia muunganisho kwa kweli, na uunganishe na jaribio hilohilo. Bila uwiano huo unasoma historia ya muunganisho mwingine na kutoa hitimisho kutoka humo.

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

Kutoka mistari hiyo, jibu maswali mawili: muungano wa awamu 1 ulianzishwa, na ubadilishanaji upi ulishindwa. Majibu hayo mawili hupunguza utafutaji hadi orodha moja ya sifa. Taarifa tupu isiyo na muktadha kuzunguka haiwezi kufanya hivyo, hata iwe ya kuvutia kiasi gani kujaribu pendekezo kutoka uzi wa jukwaa. Kunakili mfuatano unaofanya kazi kutoka mashine yenye backend nyingine kwa kawaida hubadilisha kukataa kumoja na kingine, baadaye kidogo.

Sintaksia ya backend haisafiri

Andika toleo la NetworkManager-l2tp na toleo la backend ya IPsec kabla ya kulinganisha chochote. Libreswan na strongSwan hazishiriki sintaksia ya mapendekezo wala seti zinazofanana za algoriti, kwa hivyo mfuatano unaofanya kazi katika moja ni hitilafu ya sintaksia katika nyingine. Backend iliyosakinishwa inaweza pia kukataa IKEv1 kwa sera, na wakati huo hakuna pendekezo litakalokubaliwa kamwe.

README ya mradi inaandika tofauti hizo za backend na inaweka sehemu za awamu 1 na awamu 2 tofauti. Soma kama nyaraka ya muundo, si kama mwaliko wa kuwasha kila sifa ya kihistoria na kundi dhaifu, kwa sababu muunganisho unaofanikiwa kwa njia hiyo tu si ule ulioombwa kuujenga.

Kubalianeni kuhusu seti, kisha thibitisha hatua

Muulize mwendeshaji wa lango ni seti zipi za IKE na ESP zinazoungwa mkono na zilizoidhinishwa, kisha linganisha jibu hilo na mapendekezo halisi ya mteja badala ya faili yake ya usanidi. Ikiwa kutokubaliana kunahusu hasa PFS ya awamu 2, amua kundi linaloungwa mkono au sera isiyo na PFS iliyoidhinishwa waziwazi. Usikisie sera kutoka jina la hitilafu.

Wakati mwingiliano pekee unahitaji usimbaji fiche ambao shirika halikubali tena, uamuzi ni wa lango au wa uhamishaji wa itifaki. Kupanua mfuatano wa mteja hadi kitu kijadili ni njia ya kuwasilisha udhaifu unaojulikana ukiwa na tiki ya kijani kando yake.

Baada ya kurekebisha kutokulingana halisi, thibitisha uanzishaji wa IPsec kabla ya kuchunguza L2TP na PPP, na chukua kukataa kwochote kwa uthibitishaji baadaye kama la hatua inayofuata. Kisha jaribu uhuishaji katika mchakato wa majaribio ulioidhinishwa, kwa sababu uanzishaji wa muungano wa kwanza hausemi chochote kuhusu maisha yake yaliyobaki.