L2TP NO_PROPOSAL_CHOSEN: шын мәнінде қай кезең сәтсіз аяқталды?

Хабарлама ұсыныстың қабылданбағанын айтады, бірақ қайсысын емес. Кезеңді анықтау үшін backend журналын оқыңыз, содан кейін жиынтықтарды шлюзді басқаратын адаммен салыстырыңыз.

NO_PROPOSAL_CHOSEN кез келген PPP пайдаланушы аты тексерілмей тұрып келеді, бұл пайдалы факт және сонымен бірге хабарламаның неге шатастыратынының себебі. Ол бір тарап ұсынысты қабылдамағанын хабарлайды; қай параметрдің сәйкес келмегенін хабарламайды және қабылдамау IKE бірлестігін құру кезінде болды ма, әлде кейінірек трафикті қорғау туралы келіссөз кезінде болды ма, ол туралы ештеңе айтпайды. Осы екі мүмкіндіктің артында екі түрлі түзету тұр және олардың тек біреуі адамдар бірінші ұмтылатын PFS белгілеу ұяшығына қатысты.

Бір хабарлама, екі ұсыныс жиынтығы

IKEv1 L2TP/IPsec құрылымында екі келіссөз ретімен жүреді. 1-кезең IKE қауіпсіздік бірлестігін шифрлау алгоритмінен, тұтастық алгоритмінен және Diffie-Hellman тобынан құрады. Содан кейін 2-кезең трафиктің қалай қорғалатыны туралы келіседі, ал PFS талабы сол екінші әңгімеге жатады.

PhaseWhat is agreedWhat a rejection here means
Phase 1Encryption, integrity, DH group for the IKE SANo management tunnel exists, so nothing later can run
Phase 2ESP transforms plus the PFS group policyThe IKE SA negotiates, then child negotiation fails

Кезеңдер ретімен жүретіндіктен, сәтсіздік орны қай тізімді салыстыруды айтады. Хабарламаның барлық диагностикалық құндылығы осында және оны қандай да бір параметрге қол тигізбес бұрын алып қоюға тұрарлық.

Неге PFS белгілеу ұяшығы 1-кезеңді жөндей алмайды

PFS-ті өшіру 2-кезеңнің қасиетін өзгертеді. Егер тараптар 1-кезең бойынша ешқашан келіспесе, ESP әңгімесі мүлде болмайды, сондықтан белгілеу ұяшығының қабылдамауға ешқандай әсері жоқ, сондықтан оны ауыстыру сол қатені басқа уақыт белгісімен береді.

Кері қате де соншалықты жиі. Сәтті IKE бірлестігі ESP ұсынысының қабылдануға жарамды екенін дәлелдемейді және 2-кезең тобының сәйкес келетінін әбден дәлелдемейді. Орнатылған басқару туннелін тек 1-кезең туралы дәлел ретінде қарастырыңыз. Адамдар жасыл жолды «туннель жұмыс істеп тұр» деп оқиды, содан кейін екінші келіссөз басталмағанын ешкім айтпағандықтан, дұрыс емес кезеңге бір сағат жұмсайды.

Алгоритмдерді таңдамас бұрын журналды оқыңыз

Қабылдамауға тікелей дейінгі хабарламаларды қосылымды шын мәнінде өңдейтін backend-тен жинаңыз және оларды сол әрекетпен байланыстырыңыз. Осы байланыссыз сіз басқа қосылымның тарихын оқып, одан қорытынды жасайсыз.

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

Сол жолдардан екі сұраққа жауап беріңіз: 1-кезең бірлестігі орнады ма және қай алмасу сәтсіз аяқталды. Осы екі жауап іздеуді бір атрибут тізіміне тарылтады. Айналасында контексті жоқ жалаң хабарлама мұны істей алмайды, форум тақырыбынан ұсыныс сынап көру қаншалықты қызықты болса да. Жұмыс істейтін жолды басқа backend-і бар машинадан көшіру әдетте бір қабылдамауды екіншісімен алмастырады, сәл кейінірек.

Backend синтаксисі тасымалданбайды

Бірдеңені салыстырмас бұрын NetworkManager-l2tp нұсқасын және IPsec backend нұсқасын жазып алыңыз. Libreswan мен strongSwan ұсыныс синтаксисін де, бірдей алгоритм жиынтықтарын да бөліспейді, сондықтан бірінде жұмыс істейтін жол екіншісінде синтаксистік қате. Орнатылған backend саясат бойынша IKEv1-ді де қабылдамауы мүмкін, онда ешбір ұсыныс ешқашан қабылданбайды.

Жобаның README-і осы backend айырмашылықтарын құжаттайды және 1-кезең мен 2-кезең өрістерін бөлек ұстайды. Оны құрылым құжаты ретінде оқыңыз, әр тарихи шифр мен әлсіз топты қосуға шақыру ретінде емес, өйткені тек солай ғана сәтті болатын қосылым сізден құру сұралған қосылым емес.

Жиынтық туралы келісіңіз, содан кейін кезеңдерді тексеріңіз

Шлюз операторынан қай IKE және ESP жиынтықтары қолдау тауып, бекітілгенін сұраңыз, содан кейін бұл жауапты клиенттің конфигурация файлымен емес, нақты ұсыныстарымен салыстырыңыз. Егер келіспеушілік 2-кезеңнің PFS-іне қатысты болса, қолдау тапқан топқа немесе анық бекітілген PFS жоқ саясатқа тоқталыңыз. Саясатты қате атауынан болжамаңыз.

Жалғыз қабаттасу ұйым енді қабылдамайтын криптографияны талап етсе, шешім шлюзге немесе протокол көшіруге тиесілі. Клиент жолын бірдеңе келіскенге дейін кеңейту — белгілі әлсіздікті қасында жасыл белгімен жеткізудің жолы.

Нақты сәйкессіздікті түзеткеннен кейін L2TP мен PPP-ні зерттемес бұрын IPsec орнатылғанын растаңыз және кез келген кейінгі аутентификация қабылдамауын келесі кезеңге жатады деп қарастырыңыз. Содан кейін жаңартуды бекітілген сынақ процесінде тексеріңіз, өйткені бірінші бірлестіктің орнауы оның қалған өмірі туралы ештеңе айтпайды.

Қатысты мақалалар