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 орнотулганын ырастаңыз жана кийинки кандайдыр бир аутентификация четке кагуусун кийинки баскычка таандык деп эсептеңиз. Андан кийин жаңыртууну бекитилген сыноо процессинде текшериңиз, анткени биринчи бирикменин орношу анын калган өмүрү жөнүндө эч нерсе айтпайт.

Тектеш макалалар