L2TP NO_PROPOSAL_CHOSEN: якая фаза насамрэч не ўдалася?
Паведамленне кажа, што прапанова адхілена, але не якая менавіта. Прачытайце журнал бэкенда, каб вызначыць фазу, затым параўнайце наборы з тымі, хто абслугоўвае шлюз.
NO_PROPOSAL_CHOSEN прыходзіць раней, чым правяраецца любое імя карыстальніка PPP, і гэта карысны факт, а таксама прычына, чаму паведамленне ўводзіць у зман. Яно паведамляе, што адзін бок адхіліў прапанову; яно не паведамляе, які параметр не супаў, і нічога не кажа пра тое, ці адбылося адхіленне падчас пабудовы асацыяцыі IKE або пазней падчас перамоваў пра абарону трафіку. За гэтымі двума магчымасцямі стаяць два розныя выпраўленні, і толькі адно з іх тычыцца сцяжка PFS, да якога людзі цягнуцца перш за ўсё.
Адно паведамленне, два наборы прапаноў
У схеме IKEv1 L2TP/IPsec дзве перамовы ідуць паслядоўна. Фаза 1 будуе асацыяцыю бяспекі IKE з алгарытму шыфравання, алгарытму цэласнасці і групы Diffie-Hellman. Затым фаза 2 дамаўляецца пра тое, як будзе абараняцца трафік, і патрабаванне PFS належыць менавіта да другой размовы.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
Паколькі фазы ідуць паслядоўна, месца збою паказвае, які спіс параўноўваць. У гэтым уся дыягнастычная каштоўнасць паведамлення, і яе варта выняць, перш чым чапаць наладу.
Чаму сцяжок PFS не можа выправіць фазу 1
Адключэнне PFS змяняе ўласцівасць фазы 2. Калі бакі ніколі не дамовіліся пра фазу 1, размова ESP не адбываецца наогул, таму сцяжок не ўплывае на адхіленне зусім, і менавіта таму яго пераключэнне дае тую ж памылку з іншай адзнакай часу.
Зваротная памылка сустракаецца гэтак жа часта. Паспяховая асацыяцыя IKE не даказвае, што прапанова ESP прымальная, і зусім не даказвае, што група фазы 2 супадае. Разглядайце ўсталяваны кіравальны тунель як доказ толькі пра фазу 1. Людзі чытаюць зялёную лінію як «тунель працуе», а потым марнуюць гадзіну на няправільнай фазе, бо нішто не сказала ім, што другая перамова не пачалася.
Прачытайце журнал, перш чым выбіраць алгарытмы
Сабярыце паведамленні, якія непасрэдна папярэднічалі адхіленню, з таго бэкенда, які фактычна абслугоўвае злучэнне, і суаднясіце іх з тым жа заходам. Без гэтага суаднясення вы чытаеце гісторыю іншага злучэння і робіце з яе высновы.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanПа гэтых радках адкажыце на два пытанні: ці ўсталявалася асацыяцыя фазы 1 і які абмен не ўдаўся. Гэтыя два адказы звужваюць пошук да аднаго спісу атрыбутаў. Голае паведамленне без навакольнага кантэксту гэтага не можа, як бы спакусліва ні было паспрабаваць прапанову з форуму. Капіраванне працоўнага радка з машыны з іншым бэкендам звычайна замяняе адно адхіленне іншым, трохі пазнейшым.
Сінтаксіс бэкенда не пераносіцца
Запішыце версію NetworkManager-l2tp і версію бэкенда IPsec, перш чым нешта параўноўваць. Libreswan і strongSwan не падзяляюць сінтаксіс прапаноў або аднолькавыя наборы алгарытмаў, таму радок, які працуе ў адным, з'яўляецца сінтаксічнай памылкай у другім. Усталяваны бэкенд можа таксама адмаўляць IKEv1 па палітыцы, і тады ні адна прапанова ніколі не будзе прынята.
У README праекта апісаны гэтыя адрозненні бэкендаў, і палі фазы 1 і фазы 2 там застаюцца асобнымі. Чытайце яго як апісанне структуры, а не як запрашэнне ўключыць усе гістарычныя шыфры і слабую групу, бо злучэнне, якое дасягае поспеху толькі такім чынам, не тое злучэнне, якое вас прасілі пабудаваць.
Дамовіцеся пра набор, потым праверце этапы
Спытайце ў аператара шлюза, якія наборы IKE і ESP падтрымліваюцца і зацверджаны, затым параўнайце гэты адказ з фактычнымі прапановамі кліента, а не з яго файлам канфігурацыі. Калі разыходжанне тычыцца менавіта PFS фазы 2, спыніцеся на падтрымліванай групе або на яўна зацверджанай палітыцы без PFS. Не рабіце выснову пра палітыку з назвы памылкі.
Калі адзінае перасячэнне патрабуе крыптаграфіі, якую арганізацыя больш не прымае, рашэнне належыць шлюзу або міграцыі пратакола. Пашырэнне кліенцкага радка, пакуль нешта не дамовіцца, — гэта спосаб адгрузіць вядомую слабасць з зялёнай галачкай побач.
Пасля выпраўлення сапраўднага несупадзення пацвердзіце ўсталяванне IPsec, перш чым даследаваць L2TP і PPP, і лічыце любое наступнае адхіленне аўтэнтыфікацыі якое адносіцца да наступнага этапу. Затым праверце абнаўленне ў зацверджаным тэставым працэсе, бо ўсталяванне першай асацыяцыі нічога не кажа пра астатні тэрмін яе жыцця.