L2TP NO_PROPOSAL_CHOSEN: aling yugto ba talaga ang nabigo?

Dumarating ang NO_PROPOSAL_CHOSEN bago pa suriin ang anumang pangalan ng gumagamit ng PPP, na isang kapaki-pakinabang na katotohanan at gayundin ang dahilan kung bakit nakakalito ang mensahe. Iniulat nito na tinanggihan ng isang panig ang isang panukala; hindi nito iniulat kung aling parameter ang hindi tumugma, at wala itong sinasabi tungkol sa kung nangyari ang pagtanggi habang binubuo ang asosasyong IKE o mas huli habang nakikipag-usap tungkol sa proteksyon ng trapiko. Sa likod ng dalawang posibilidad na iyon ay may dalawang magkaibang pagwawasto, at isa lang sa kanila ang may kinalaman sa kahon ng PFS na unang hinahawakan ng mga tao.

Isang mensahe, dalawang hanay ng panukala

Ang kaayusang IKEv1 L2TP/IPsec ay may dalawang negosasyon na magkakasunod. Binubuo ng yugto 1 ang asosasyong pangseguridad ng IKE mula sa algorithm ng pag-encrypt, algorithm ng integridad, at pangkat na Diffie-Hellman. Pagkatapos ay nakikipag-usap ang yugto 2 kung paano poprotektahan ang trapiko, at ang pangangailangan ng PFS ay kabilang sa ikalawang usapang iyon.

Dahil magkakasunod ang mga yugto, sinasabi ng lokasyon ng kabiguan kung aling listahan ang ihahambing. Doon nakalagay ang buong halaga ng dayagnostiko ng mensahe, at sulit itong ilabas bago hawakan ang anumang setting.

Bakit hindi kayang ayusin ng kahon ng PFS ang yugto 1

Binabago ng pag-off ng PFS ang isang katangian ng yugto 2. Kung kailanman ay hindi nagkasundo ang magkabilang panig sa yugto 1, hindi mangyayari ang usapan ng ESP, kaya walang anumang epekto ang kahon sa pagtanggi, at iyon ang dahilan kung bakit ang pagpapalit nito ay nagbibigay ng parehong error na may ibang timestamp.

Ang kabaligtarang pagkakamali ay kasingkaraniwan. Hindi pinatutunayan ng matagumpay na asosasyong IKE na katanggap-tanggap ang panukalang ESP, at talagang hindi nito pinatutunayan na tugma ang pangkat ng yugto 2. Ituring na ebidensya lamang tungkol sa yugto 1 ang naitatag na tunnel ng pamamahala. Binabasa ng mga tao ang berdeng linya bilang «buhay ang tunnel,» pagkatapos ay gumugugol ng isang oras sa maling yugto dahil walang nagsabi sa kanila na hindi pa nagsisimula ang ikalawang negosasyon.

Basahin ang log bago pumili ng mga algorithm

Tipunin ang mga mensaheng nauna sa pagtanggi mula sa backend na talagang humahawak ng koneksyon, at iugnay ang mga ito sa parehong pagtatangka. Kung wala ang ugnayang iyon ay binabasa mo ang kasaysayan ng ibang koneksyon at kumukuha ng mga konklusyon mula rito.

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

Mula sa mga linyang iyon, sagutin ang dalawang tanong: naitatag ba ang asosasyon sa yugto 1, at aling palitan ang nabigo. Ang dalawang sagot na iyon ay nagpapaliit ng paghahanap sa isang listahan ng katangian. Hindi kayang gawin iyon ng hubad na abiso na walang konteksto sa paligid nito, gaano man kaakit-akit na subukan ang isang panukala mula sa isang thread sa forum. Ang pagkopya ng gumaganang string mula sa makinang may ibang backend ay karaniwang pumapalit ng isang pagtanggi ng isa pa, mas huli nang kaunti.

Hindi naglalakbay ang sintaks ng backend

Itala ang bersyon ng NetworkManager-l2tp at ang bersyon ng backend ng IPsec bago ihambing ang anuman. Hindi nagbabahagi ang Libreswan at strongSwan ng sintaks ng panukala o magkatulad na hanay ng algorithm, kaya ang string na gumagana sa isa ay error sa sintaks sa isa pa. Maaari ring tanggihan ng naka-install na backend ang IKEv1 ayon sa patakaran, at kung gayon ay walang panukalang matatanggap kailanman.

Dinodokumento ng README ng proyekto ang mga pagkakaibang iyon sa backend at pinaghihiwalay ang mga patlang ng yugto 1 at yugto 2. Basahin ito bilang dokumentasyon ng istruktura, hindi bilang paanyayang i-on ang bawat makasaysayang cipher at isang mahinang pangkat, dahil ang koneksyong nagtatagumpay lamang sa paraang iyon ay hindi ang koneksyong hiniling sa iyong buuin.

Magkasundo sa suite, pagkatapos ay i-verify ang mga yugto

Tanungin ang operator ng gateway kung aling mga suite ng IKE at ESP ang sinusuportahan at inaprubahan, pagkatapos ay ihambing ang sagot na iyon sa aktwal na mga panukala ng kliyente kaysa sa file ng configuration nito. Kung ang hindi pagkakasundo ay partikular sa PFS ng yugto 2, magpasya sa isang sinusuportahang pangkat o sa isang hayagang inaprubahang patakarang walang PFS. Huwag mahinuha ang patakaran mula sa pangalan ng error.

Kapag ang tanging pagtutugma ay nangangailangan ng kriptograpiyang hindi na tinatanggap ng organisasyon, ang desisyon ay pag-aari ng gateway o ng isang paglipat ng protocol. Ang pagpapalawak ng string ng kliyente hanggang may makipag-ayos ay isang paraan ng paghahatid ng kilalang kahinaan na may berdeng tsek sa tabi nito.

Pagkatapos itama ang tunay na pagkakaiba, kumpirmahin ang pagtatatag ng IPsec bago imbestigahan ang L2TP at PPP, at ituring ang anumang susunod na pagtanggi sa pagpapatotoo bilang kabilang sa susunod na yugto. Pagkatapos ay subukan ang pag-renew sa inaprubahang proseso ng pagsubok, dahil ang pagtatatag ng unang asosasyon ay walang sinasabi tungkol sa natitirang buhay nito.