Хоёр зөөврийн компьютер нэг гэрийн сүлжээнд байна, офисийн VPN тэдгээрийн яг нэгийг л хүлээн авдаг. Хоёр дахь нь хугацаа дуусах эсвэл эхнийх нь салтал хүлээнэ, хоёр оролдлогын хооронд хэн ч клиентийн тохиргоог хөндөөгүй. Нэвтрэх мэдээлэл нэг минутын өмнө ажиллаж байсантай ижил, энэ нь баталгаажуулалт алдааны шалтгаан биш гэсэн сэжүүр юм. Энэ хэв маягийг гурван механизм үүсгэдэг, та аль нь болохыг серверийн өөрийнх нь лог хэлж өгнө.

Клиентэд хүрэхээс өмнө гарцын логыг уншина уу

Хоёр оролдлогын тухай серверийн бүртгэл эхний асуултад хариулдаг, гурван аргын нэгээр хариулдаг. Хоёр дахь оролдлого тэр лог дээр огт харагдахгүй бол пакет сонсогчдод хүрээгүй, асуудал гэрийн чиглүүлэгч эсвэл үйлчилгээ үзүүлэгчийн замд байна. Лог оролдлогыг бүртгэж, түүнийгээ татгалзвал туннель ирсэн, өөрөөр хэлбэл асуудал таних тэмдэг, лиценз эсвэл сессийн хязгаарт байна, утсан дээрх зүйлд биш. Лог амжилттай сессийг бүртгэж байхад клиент алдаа мэдээлсээр байвал буцах зам эсвэл хоёр клиентэд нэг туннелийн хаяг өгч байгаа эсэхийг харна уу.

Утасны хотспот тэдгээр гэр бүлийг хямдхан ялгадаг: эхнийх холбогдсон байхад хоёр дахь клиентийг мобайл мэдээллээр ажиллуулна уу. Тэнд амжилт гэрийн сүлжээг заана, тэнд ижил алдаа гарцыг заана, энэ нь чиглүүлэгчийг гэмгүй үлдээнэ. Аль ч үр дүн дангаараа шийдвэрлэхүйц биш, гэхдээ тус бүр нэг оролдлогоор хайлтын талбайн талыг арилгана.

Ямар нэгэн зүйл өөрчлөхөөс өмнө үр дүнг бичиж аваарай, учир нь логын гурван үр дүн гурван хамааралгүй засварт хүргэдэг. Гурвын алийг нь харсанаа тэмдэглэсэн тэмдэглэл клиентийн алдааны дэлгэцийн зурагнаас илүү үнэ цэнэтэй.

Чиглүүлэгч GRE ба NAT-T-тэй юу хийдэг вэ

PPTP бол сонгодог гэмтэн: удирдлагын суваг нь TCP 1723, харин өгөгдлийн зам нь GRE, өөрөөр хэлбэл IP протокол 47. Олон хэрэглэгчийн чиглүүлэгч нэг удирдлагын холболтыг дагадаг PPTP туслахтай ирдэг тул нэг NAT-ийн ард байгаа хоёр дахь клиент өөрийн удирдлагын сувгийг нээгээд дараа нь өгөгдлийн зам огт авдаггүй. 47 дугаар TCP портыг дамжуулах нь GRE-д юу ч хийдэггүй, учир нь GRE нь порт биш, протоколын дугаар юм.

L2TP IPsec дээр зохион бүтээлээрээ өөрөөр ажилладаг: IKE нь UDP 500 ашигладаг, NAT дамжуулалт хамгаалагдсан ачааг UDP 4500 руу зөөдөг, капсулчлал нь нэг хаягийн ард байгаа хэд хэдэн клиент нэг гарцад хүрэхэд зориулагдсан. Энэ зохион бүтээл гарц эсвэл завсрын хайрцаг хаяг тус бүрт сессийн хязгаар тогтоохоос сэргийлдэггүй, буйдан дээрээс харвал хоёр алдаа ижил харагдана. SoftEther-ийн өөрийн протоколд ч мөн адил ангиллын асуудал бий: ажилладаг дамжуулалтгүй чиглүүлэгч LAN-аас эхний клиентийг оруулаад хоёр дахийг нь хаядаг. Чиглүүлэгчийн ALG эсвэл дамжуулалтын унтраалгыг хоёр байрлалд туршиж үзээрэй, учир нь хуучин клиентэд зориулж бичсэн туслах одоогийн клиентийн илгээсэн пакетыг гэмтээж болно.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

Тээврийн хязгаар мэт харагдах таних тэмдгийн хязгаарууд

Чиглүүлэгч бол цорын ганц сэжигтэн биш, лог нь түүнийг өөр хувилбараас ялгадаг. OpenVPN сервер нийтлэг нэрийг нэг туннелийн хаягт холбоход хоёр төхөөрөмж тэр хаягийг авдаг, duplicate-cn гүйгээр шинэ сесс хуучин сессийг шахаж гаргадаг. Тэр сонголтыг асаахад хоюулаа холбогдсон хэвээр үлддэг ч нэг таних тэмдэг, нэг гэрчилгээ, нэг хүчингүй болгох шийдвэртэй үлддэг, энэ нь харагдахаас ч дор. Тэгэхэд хоёр дахь төхөөрөмжийг хэзээ ч дангаар нь хүчингүй болгож чадахгүй тул тав тухыг хангах унтраалга дараа нь хэрэгтэй болох хяналтыг чимээгүйхэн хасдаг.

Серверийн журнал болон түүний төлөвийн файлыг хамт уншина уу, учир нь нэг нь баталгаажуулалтын шийдвэрийг, нөгөө нь одоо хэн холбогдсоныг харуулдаг. Нэг нийтлэг нэр, нэг виртуал хаягыг хуваалцсан хоёр бичлэг чиглүүлэгчийн хязгаар биш, таних тэмдгийн мөргөлдөөнийг батална. Арилжааны гарцууд өөрсдийн хязгаарыг нэмдэг, жишээ нь нэг зэрэг нэг сессийг зөвшөөрдөг багц, лицензийн тоо, эсвэл нийтийн хаяг бүрт нэг сессийг зөвшөөрдөг дүрэм, чиглүүлэгчийн ямар ч тохиргоо эдгээрийн алийг нь ч өөрчлөхгүй.

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

Засварыг логын бичлэгтэй тааруулна уу

Лог дээрх татгалзал нь төхөөрөмж тус бүрийн тусдаа нэвтрэх мэдээлэл, үйлчилгээг ажиллуулагчаас илүү өндөр хязгаар, эсвэл нэг машинд зориулсан хоёр дахь гарцын төгсгөлийн цэгийг шаарддаг. Хоёр дахь оролдлого хэзээ ч серверт хүрэхгүй бол байнгын засвар нь протоколыг дамжуулж, нэгээс олон сессийг барьдаг чиглүүлэгч, эсвэл чиглүүлэгч сайн зохицуулдаг тээвэр, жишээ нь нэг TCP эсвэл UDP урсгал юм. Тэдгээрийн дундаас сонгох нь техник хангамжийн наслалтын тухай шийдвэр, клиентийн тохиргооны тухай биш.

Ажиллаж байгаа төхөөрөмжийн профайлыг хоёр дахь машин руу хуулж, ажлыг дууссан гэж битгий бодоорой. Энэ нь холболтын асуудлыг хандалтын хяналтын асуудал болгон хувиргадаг, учир нь алдсан зөөврийн компьютер ашиглалтад байгаа хуулбараас ялгагдахгүй болдог. Энэ нь мөн анхны гэмтлийг нуудаг, гурав дахь төхөөрөмж гарч ирэх тэр мөчид буцаж ирдэг.

Хоёр амьд сессийг шалгах

Хоёр төхөөрөмжийг нэгэн зэрэг холбоно уу, тус бүрд нь зориулсан програмыг ажиллуулна уу, дараа нь нэгийг нь дахин холбож давтана уу. Хормын дотор харагдах хоёр дахь дүрс траффикийн талаар юу ч батлахгүй, арван минутын дараа унадаг сесс бол өөр эзэнтэй өөр гэмтэл юм. Сервер төгсгөлд мэдээлж байгааг хэрэглэгчдийн харсантай харьцуулна уу, учир нь эдгээр хоёр өгүүлэмж ихэвчлэн нийцдэггүй.

Хоёр сесс амьд үлдэж траффик зөөвөл засвар тогтвортой, эхэнд бичсэн тэмдэглэл юу буруу байсны бүртгэл болно. Зөвхөн нэг нь үлдвэл эхний алхам руу буцаж, одоо логын гурван үр дүнгийн алийг нь аваад байгаагаа шалгана уу, учир нь хариулт өөрчлөгдсөн байж болно. Чиглүүлэгчийн туслахууд өөр сүлжээнд дахин гарч ирэх асуудлыг нууж болно, харин хаяг тус бүрийн хязгаар нь төхөөрөмжийг биш, хэрэглэгчийг дагадаг. Хоёр дахь сүлжээнээс турших нь эдгээрийн алийг нь үнэхээр зассан болохыг мэдэх хамгийн хямд арга юм.

Холбоотой нийтлэлүүд