VPN-ийн аль үе шат бүтэлгүйтсэн бэ: IPsec, L2TP удирдлага эсвэл PPP баталгаажуулалт
Хамгийн сүүлийн амжилттай үе шатыг олж, зөвхөн тэр давхаргыг засаарай: IPsec, L2TP удирдлагын суваг, PPP баталгаажуулалт эсвэл хаяг олголт.
Нууц үгээ сольсон боловч юу ч хөдөлсөнгүй, учир нь алдаа хэзээ ч PPP-д байгаагүй. L2TP/IPsec таван огт өөр дамжуулалтад нэг холболтын алдаа мэдээлдэг бөгөөд дамжуулалт бүр өөрийн засварын аргатай. Эсрэг чиглэлд ажиллаарай: хамгийн сүүлийн амжилттай үе шатыг олж, түүний дараа ирэх зүйлийг л өөрчил. Доорх дараалал нь аль нотолгоог эхлээд цуглуулахыг ч тодорхойлно.
Дөрвөн асуултад дарааллаар нь хариулаарай
Шинэ оролдлогыг албадаарай, учир нь зарим клиент профайлыг салгаж дахин холбох хүртэл өмнөх алдааг харуулсаар байдаг. Дараа нь үүнд хариулаарай: IPsec аюулгүй байдлын холбоо байсан уу, L2TP удирдлагын холболт ба дуудлага гарч ирсэн үү, PPP баталгаажуулалтын шийдвэрт хүрсэн үү, IPCP клиентэд хаяг өгсөн үү? Эхний үгүй бол таны засах үе шат. Түүний дараах бүхэн шалгагдаагүй, тиймээс холбоо хэзээ ч байгаагүй бол татгалзсан хэрэглэгчийн нэр юу ч батлахгүй.
Харьцуулахын өмнө хоёр төгсгөлийн цагийг синхрончилоорой. IPsec-ийг цэвэрлээд PPP-д бүтэлгүйтсэн дахин оролдлого нь клиент зөвхөн сүүлийн мессежийг харуулж, серверийн лог өмнөх оролдлогыг хадсаар байхад нэг л алдаа мэт харагдана. Хамгийн чанга мөрөөр биш, цагийн тэмдэглэгээгээр уншаарай.
Зөвхөн хэрэглэгчийн дэлгэцийн зураг байвал хамгийн хямд хуваалтад найдаарай: буруу урьдчилан хуваалцсан түлхүүр болон хэзээ ч хариу өгдөггүй xl2tpd Windows-ийн диабогт ижил текст үүсгэдэг, гэхдээ нэг нь хоёр төгсгөлд сольсон нууц шаарддаг, нөгөө нь сервер дээрээ демон асаах эсвэл галт ханын дүрэм шаарддаг. Дунд байгаа төхөөрөмж нь тээврийн горимын 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 missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, 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-ийг чангалах хэрэгтэй. Хуваагдсан туннелийн маршрутжуулалт нь өөр нэг хуурамч; буруу маскатай илгээсэн дэд сүлжээ нь туннелийг эрүүл, нэг аппликейшныг хүрэхгүй үлдээдэг. Хувийн хостын нэр өөрийн алхмыг нэмдэг: асуулга локал шийдэгчээр гарвал ямар ч маршрут шалгагдахаас өмнө нэр шийдэгдэхгүй.
Итгэмжлэлд хүрэхээс өмнөх шалгах хуудас
Жагсаалтыг дарааллаар нь хийж, эхний бүтэлгүйтсэн зүйл дээр зогсоорой. Алхам бүр хямд бөгөөд алхам бүр засварын бүхэл ангиллыг хасаж өгдөг.
- Холбоо хоёр төгсгөлд байгаа эсэхийг батал, холбогдсон шошгоор биш, түншийн хэн болохоор тааруулж.
- UDP 1701 xl2tpd-д хүрч байгаа эсэхийг батал; дуудлагагүй холбоо бол таны алдаа.
- Нууц үг буруу гэж бодохоос өмнө PPP-ийн шийдвэрийг, баталгаажсан бол IPCP-ийн үр дүнг уншаарай.
- Одоо л итгэмжлэлийг серверийн хүлээж буй хэлбэрээр дахин оруулаарай, учир нь домэйн угтвар дансыг өөрчилдөг.
- Хэрэв дахин бүтэлгүйтвэл хоёр төгсгөлийг зэрэгцүүлсэн цагийн тэмдэглэгээтэй бичиж аваад шат шатаар харьцуулаарай.
Хоёр дахь алхам дээр зогсох нь зам эсвэл капсулчлалын асуудал бөгөөд нууц үгийн ямар ч засвар түүнийг хөдөлгөхгүй. Гурав дахь алхам дээр зогсох нь лог засах арга эсвэл хаягийн санг аль хэдийн нэрлэсэн гэсэн үг. Аль ч тохиолдолд дараагийн өөрчлөлт нь таны үндэслэж чадах өөрчлөлт бөгөөд хэзээ ч оролцоогүй тохиргоонуудыг тойрон эргэлдэхээ болино.