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 множества се поддржани и одобрени, па споредете го тој одговор со вистинските предлози на клиентот, а не со неговата конфигурациска датотека. Ако несогласувањето е конкретно за PFS на фазата 2, одлучете се за поддржана група или за изречно одобрена политика без PFS. Не ја изведувајте политиката од името на грешката.

Кога единствениот преклоп бара криптографија што организацијата веќе не ја прифаќа, одлуката и припаѓа на портата или на миграција на протоколот. Ширењето на клиентската низа додека нешто не преговара е начин да се испорача позната слабост со зелена ознака до неа.

Откако ќе ја исправите вистинската неусогласеност, потврдете го воспоставувањето на IPsec пред да ги истражите L2TP и PPP, и третирајте го секое подоцнежно одбивање на автентикација како да припаѓа на следната етапа. Потоа испробајте го обновувањето во одобрениот процес за тестирање, зашто воспоставувањето на првото здружение не кажува ништо за остатокот од неговиот век.

Поврзани статии