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

Хөдөлгөөн хаана зогсдогийг батлаарай

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

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

PPTP 47-р протоколгүйгээр үхдэг

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

Дамжуулалт нь ирж буй дамжуулалтын эсрэг чиглэлд ажилладаг бөгөөд програм хангамж хоёуланд нь нэг шошгыг хангалттай олон удаа ашигладаг тул бүгдийг төөрөгдүүлдэг. Linux клиент дээр локал галт хана чиглүүлэгч оролцохоос хамаагүй өмнө GRE-г хаяж болох тул 47-р протоколд өөрийн дүрэм хэрэгтэй бөгөөд conntrack туслахыг ачаалах ёстой. Ubuntu-гийн ufw эдгээр дүрмийг before файлд хадгалдаг, учир нь энгийн allow дүрэм протоколын дугаарыг илэрхийлж чадахгүй. Дараа нь машиныг дахин асаахын оронд галт ханыг дахин ачаал.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

Хоёр NAT-ын ард L2TP ба IPsec

L2TP IPsec дотор түлхүүр солилцоход UDP 500, NAT илэрсэн үед UDP 4500, мөн протокол 50 болгож ESP шаарддаг. Тэдгээрийн нэг бүр тусдаа шүүгддэг тул нэгийг зөвшөөрсөн дүрэм нөгөө хоёрын талаар юу ч батлахгүй. Цуваа хоёр чиглүүлэгч пакет бүрийг хоёр удаа хөрвүүлдэг бөгөөд төгсгөлүүд юу хэлэлцсэн талаар цаашид санал нийлэхгүй.

Гадаад модемыг гүүрэн горимд оруул эсвэл дотоод чиглүүлэгч дээр NAT-ыг унтраа, ингэснээр нийтийн хаяг туннелийг дуусгаж буй төхөөрөмжид хүрнэ. Аль нь ч боломжгүй бол туннелийг давхар NAT-ын хил дотроос эхлүүлэх ёстой, тэнд дуусгах ёсгүй.

Операторын сүлжээ ба хаяг хуваалцах

WAN хаяг 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 эсвэл 100.64.0.0/10 дотор байвал чиглүүлэгчид нийтийн хаяг байхгүй бөгөөд интернэтээс ирэх ямар ч дамжуулалт түүнд хүрч чадахгүй. Операторын түвшний NAT хүлээгээгүй протоколуудыг нэмж шүүдэг бөгөөд гар утасны холболтод GRE ихэвчлэн хохирдог. WAN хаягыг чиглүүлэгч дээр нь харьцуул, түүний ард байгаа клиентийн хувьд хайлтын сайт мэдээлсэн хаягтай биш.

Мөн чиглүүлэгчийг утсан шугам дээр ажиллуулах нь нэг тестээр операторын дүгнэлтийг тохиргооны алдаанаас тусгаарладаг. Оператор протоколоос татгалзвал үлдэх сонголт нь 443 дээрх өөр тээвэр эсвэл дотроос эхэлсэн туннель юм.

Портуудыг хаахаас өмнө сонсогчдын жагсаалтыг уншаарай

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

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

SoftEther-ийн анхдагч утгууд сайн жишээ: TCP 443, 992 ба 5555, харин L2TP/IPsec ба DNS-туннелийн функцууд өөрийн сокетуудыг нэмдэг. Эдгээр функцийг унтраах нь сонсогчдыг нуухын оронд арилгадаг бөгөөд гадаад хостноос хийсэн шалгалт оператор портыг огт нэвтрүүлж байгаа эсэхийг хэлнэ. Локалд хариу өгдөг сонсогч дээд талд хаалттай байж болох тул чиглүүлэгчийн өөрийн WAN хаягыг гадаад үйлчилгээний мэдээлсэнтэй харьцуул.

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