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, и третирайте всяко следващо отхвърляне на автентикация като принадлежащо на следващия етап. После проверете подновяването в одобрения тестов процес, защото установяването на първата асоциация не казва нищо за остатъка от живота ѝ.