Құпия сөзді өзгерттіңіз, бірақ ештеңе өзгермеді, өйткені ақау ешқашан PPP-де болған емес. L2TP/IPsec бес мүлдем басқа беріліс үшін бір қосылым қатесін хабарлайды және әр берілістің өз жөндеуі бар. Керісінше жұмыс істеңіз: сәтті аяқталған соңғы кезеңді тауып, тек одан кейін келетінін өзгертіңіз. Төмендегі тәртіп қай дәлелді бірінші жинайтыныңызды да анықтайды.

Төрт сұраққа ретімен жауап беріңіз

Жаңа әрекетті мәжбүрлеңіз, өйткені кейбір клиенттер профиль ажыратылып, қайта қосылғанша алдыңғы қатені көрсете береді. Содан кейін мынаған жауап беріңіз: IPsec қауіпсіздік ассоциациясы болды ма, L2TP басқару қосылымы мен шақыру пайда болды ма, PPP аутентификация шешіміне жетті ме және IPCP клиентке мекенжай берді ме? Бірінші жоқ — сіз түзететін кезең. Одан кейінгінің бәрі тексерілмеген, сондықтан ассоциация ешқашан болмаса, қабылданбаған пайдаланушы аты ештеңені дәлелдемейді.

Салыстыру алдында екі жақтағы сағаттарды синхрондаңыз. IPsec-ті тазалап, PPP-де сәтсіз аяқталған қайталау, клиент тек соңғы хабарламаны көрсетіп, сервер журналы әлі де алдыңғы әрекетті сақтаған кезде бір ақау болып көрінеді. Ең қатты жол бойынша емес, уақыт белгісі бойынша оқыңыз.

Қолыңызда тек пайдаланушының экран суреті болса, ең арзан бөлуге сүйеніңіз: қате алдын ала ортақ кілт пен ешқашан жауап бермейтін xl2tpd Windows диалогында бірдей мәтін шығарады, бірақ біреуіне екі жақта өзгертілген құпия керек, екіншісіне сервердің өзінде іске қосылған демон немесе firewall ережесі керек. Ортадағы құрылғы транспорт режиміндегі IPsec оны орағаннан кейін ішкі 1701-ді тастай алмайды, сондықтан жоқ жол сүзгісін іздемеңіз.

Әр қабат шын мәнінде нені иеленеді

IPsec екі серіктес арасындағы пакеттерді қорғайды; L2TP сол қорғалған жолдың ішінде PPP сессиясын тасымалдайды, сондықтан RFC 3193 өз туннелінің орнына транспорт режимін белгілейді. Клиент белгісі L2TP дейді, сондықтан туннель мен кіру бір механизм болып көрінеді. Олай емес: L2TP басқару қосылымы орналастыру оны қосқан жерде туннельдің шеттерін аутентификациялайды, ал PPP сервер саясатына сәйкес пайдаланушыны CHAP, PAP немесе MS-CHAPv2 арқылы бөлек аутентификациялайды.

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

Аутентификация да PPP-дің соңы емес. Пайдаланушы қабылданғаннан кейін IPCP клиенттің мекенжайы мен сервер беруге дайын DNS және WINS параметрлері туралы келіседі. Клиент CHAP немесе MS-CHAPv2-ден өтіп, бәрібір мекенжайсыз қалуы мүмкін, бұл PPP ішіндегі ақау, маршруттау мәселесі емес. IPsec-сіз қарапайым L2TP жарамды және қорғалмаған күйде қалады, сондықтан сәтті қосылым трафиктің қорғалғанын ешқашан дәлелдемейді; сервердің нені талап ететінін тексеріңіз, клиент белгісін емес.

Бірінші жетіспейтін кезең бойынша шешіңіз

Кестені бірінші жетіспейтін элемент бойынша солдан оңға оқыңыз. Оң жақ баған сол сәтте тұрарлық жалғыз жұмыс; оның сол жағындағының бәрі дәлелденген, ал оны қайта тексеру ақпарат қоспай-ақ үзіліс терезесін жағып жібереді.

First thing missingWhat it meansChange this
No IKE reply on 500 or 4500The path or the listener never answeredFirewall, NAT-T forwarding, server listener
IKE runs, no IPsec associationIdentity, key, or proposal mismatchProposal and PFS set, pre-shared key, local and remote ID
Association up, no L2TP control connectionInner signalling never reached xl2tpdUDP 1701, tunnel and session sections, NAT encapsulation
Control connection up, PPP auth refusedThe user or method was rejectedCredential format, allowed auth method, account policy
PPP auth accepted, no address assignedIPCP never completedAddress pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd
Address assigned, applications failThe inner path is wrongRoutes, DNS, MTU or MSS, server forwarding

Үш жол ескертуге лайық. 1701 жолы — NAT артындағы Windows клиенттері әдетте түсетін жер: ассоциация аяқталады, содан кейін ештеңе келмейді, ал себебі нашар құпия сөз емес, инкапсуляция. IPCP жолы — маршрут мәселесі деп қате оқылатын жол, өйткені Windows жетіспейтін мекенжайды 720 қатесіне орап, трей белгішесі тек қосылым сәтсіз аяқталғанын айтады; бұл ақау аутентификациядан кейін және маршруттауға дейін тұр. Соңғы жол мүлдем IPsec ақауы емес, белгіше ажыратылған десе де.

Қабаттарды ажырататын командалар

strongSwan жұмыс істейтін Linux серверінде swanctl --list-sas орнатылған ассоциацияларды серіктес жеке басымен тізімдейді, ал ipsec statusall ескірек strongSwan және libreswan хосттарын қамтиды. Оның астында ip xfrm state ядроның нақты ассоциацияларын көрсетеді, ал ss -lunp | grep 1701 xl2tpd қайда байланғанын дәлелдейді. Басқару қосылымдары мен шақырулардың пайда болуын көру үшін xl2tpd -D-ті алдыңғы планда іске қосыңыз, ал ұсынылған әдіс пен жауапты көру үшін /etc/ppp/options.xl2tpd ішінде pppd жөндеуін қосыңыз.

Журналдар сәтті аутентификацияны көрсеткенде, келесі сұрақ — IPCP аяқталды ма. /etc/xl2tpd/xl2tpd.conf файлының [lns default] бөліміндегі ip range-де әлі бос мекенжайлар бар-жоғын және клиент күтсе, /etc/ppp/options.xl2tpd шынымен ms-dns мен ms-wins-ны алып жүргенін тексеріңіз. Сарқылған пул мен жетіспейтін DNS параметрі сымда басқаша көрінеді: біріншісі клиентті мекенжайсыз және 720-мен қалдырады, екіншісі мекенжай береді, бірақ шешуші бермейді, сондықтан атаулар сәтсіз, ал шикі мекенжайларға ping жұмыс істейді. Екеуі де құпия сөзді қайта енгізумен түзелмейді.

Клиентте NetworkManager-дің L2TP қосымшасы pppd әңгімесін журналға жазады, сондықтан journalctl -u NetworkManager -b әдетте туннель көтерілді, аутентификация қабылданбады күйін мүлдем туннель жоқ күйінен ажыратады. Windows-та Get-VpnConnection профильдің нақты аутентификация параметрлерін хабарлайды, ал Event Viewer-де Application астындағы RasClient оқиғалары сәтсіз компонентті атайды. Диалог тым бұлыңғыр болса, netsh ras set tracing * enable қосыңыз.

Жазбалар бір сақтықты қажет етеді. Транспорт режиміндегі IPsec кезінде ішкі UDP 1701 шифрланған, сондықтан сыртқы интерфейстегі жазба ESP көрсетеді, немесе NAT-T астында UDP 4500, және мүлдем L2TP жоқ. Жазбада 1701 болмауы күтілетін жағдай және бұғатталған порттың дәлелі емес; ESP немесе 4500 есептегіштері қозғала ма, бақылаңыз.

NAT, MTU және маршруттар: стек сізді қайда адастырады

NAT бірдеңе аутентификацияланбай тұрып болжамдарды бұзады. ESP — жеке IP протоколы, сондықтан аударатын құрылғы оны серіктестер инкапсуляцияламаса тастайды; мұны UDP 4500 қамтамасыз етеді. Өзі үй роутерінің немесе бұлттық NAT қақпасының артында тұрған Windows серверінде IPsec кезеңі 789 қатесімен сәтсіз аяқталады, PolicyAgent кілті астында AssumeUDPEncapsulationContextOnSendRule 2-ге қойылып, машина қайта жүктелмейінше, және ақау жабық порттан ажыратылмайды. NAT артындағы клиенттер оңайырақ: серверде жария мекенжай болса, UDP 4500 үстіндегі NAT-T оларды тасымалдайды және бұл мән қатыспайды.

PPP көтерілгенде, қара шұңқырлы MTU өлі туннельді имитациялайды: шағын пакеттер өтеді, TLS қол алысуы немесе бетті жүктеу ілініп қалады, ал клиент әлі де қосылған көрсетуі мүмкін. Серверді кінәламас бұрын интерфейс MTU-ын төмендетіңіз немесе қақпада MSS-ті қысыңыз. Бөлінген туннель маршруттауы — екінші алдамшы; қате маскамен жіберілген қосалқы желі туннельді сау, ал бір қолданбаны қолжетімсіз қалдырады. Жеке хост атауы өз қадамын қосады: сұрау жергілікті шешуші арқылы шықса, ешбір маршрут тексерілмей тұрып атау шешілмейді.

Тіркелгі деректеріне қол тигізбес бұрынғы тексеру тізімі

Тізімді ретімен орындаңыз және бірінші сәтсіз тармақта тоқтаңыз. Әр қадам арзан, және әрқайсысы түзетулердің тұтас бір класын жоққа шығарады.

  1. Ассоциацияның екі жақта да бар екенін растаңыз, қосылған белгісімен емес, серіктес жеке басымен сәйкестендіріп.
  2. UDP 1701 xl2tpd-ге жететінін растаңыз; шақырусыз ассоциация — сіздің ақауыңыз.
  3. Құпия сөз қате деп ойламас бұрын PPP үкімін, ал аутентификацияланса, IPCP нәтижесін оқыңыз.
  4. Тек қазір тіркелгі деректерін сервер күтетін форматта қайта енгізіңіз, өйткені домен префиксі тіркелгіні өзгертеді.
  5. Егер әлі де сәтсіз болса, екі жақты тураланған уақыт белгілерімен жазып алып, кезең-кезеңімен салыстырыңыз.

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

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