VPN гэрт холбогддог ч зочид буудлын Wi-Fi-д хугацаа хэтэрдэг

Зөөврийн компьютер гэрийн Wi-Fi-д холбогдож, клиент гурван секундэд холбогдож, ижил профайл нэг цагийн дараа зочид буудалд бүтэлгүйтдэг. Хооронд нь юу ч шинэчлэгдээгүй. Үүнийг урд чинь сууж буй клиенттэй хамт үзэх нь гол төлөв аль алдаа аль үе шатанд хамаарахыг мэдэх тухай юм, учир нь хэрэгтэй мэдээлэл клиентийн хэвлэдэг кодонд байдаг, тэр бүтэлгүйтсэн гэдэгт биш. Доорх дөрвөн алхмыг дарааллаар гүйцэтгэвэл нэр, пакет, порт эсвэл бодлого таныг татгалзсаныг мэдэх болно.

Алдааны кодыг шийтгэл биш, үе шат гэж унш

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

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

Клиент Windows биш бол зохих хэмжээнд болгоомжтой бай. Гуравдагч талын клиентүүд үүний ихэнхийг "холболт амжилтгүй" болгон хураангуйлдаг тул дараагийн хоёр алхам мэдэгдэлд огт тулгуурладаггүй.

Туннелийг буруутгахаас өмнө нэрийг шалга

Зочид буудал, нисэх онгоцны буудлын сүлжээ DNS-ийг байнга барьж авдаг бөгөөд порталын хаягаар хариулдаг шийдэгч үхсэн сервертэй яг адил харагдах бүтэлгүйтэл үүсгэдэг. Орон нутгийн шийдэгчийн хэлснийг нийтийн шийдэгчийн хэлсэнтэй харьцуул:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

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

Одоо хүрэхийг хүсч буй хаяг чинь ашиглагдаж буй хаяг мөн эсэхийг батал. Зарим клиент өмнөх шийдлийг профайлын бүх амьдралын туршид кэшлэдэг тул DNS өөрчлөгдсөний дараах дахин холболт хуучин хаяг руу явсаар байна. Дахин шалгахаас өмнө клиентийг бүрэн хаа, нэг цонхонд салгах ба холбох товчийг дарахаас илүү.

Аль гадаад пакет алга болохыг тогтоо

Туннель нь таны болон серверийн хоорондох замд бүрэн хамаарах гадаад урсгалтай бөгөөд яг тэр урсгалыг завсрын хайрцагууд ангилж хаядаг. Үүнийг клиент дээр барьж аваад ажиллаж буй сүлжээг бүтэлгүйтэж буй сүлжээтэй харьцуул. Windows дээр эхний харцад суурилагдсан бичлэг хангалттай:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

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

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

Нэг зөөвөрлөх аргыг сольж дахин шалга

Гадаад урсгалыг хаяж байгааг мэдсэний дараа практик асуулт нь сүлжээ ямар урсгалыг зөвшөөрдөг вэ гэдэг юм. Ихэнх хязгаарлагдмал сүлжээ гадагш TCP 443-ыг зөвшөөрдөг, эс тэгвээс ажиллаж чадахгүй, тиймээс сонсогчийг тэнд зөөх нь ердийн хариулт юм. OpenVPN дээр сервер солигдох хүртэл энэ нь клиентийн талын унтраалга:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

IPsec клиентүүд өөрийн тохиргооны самбарт ижил унтраалгатай бөгөөд ихэвчлэн TCP дээгүүр IPsec эсвэл NAT дамжуулалт гэж тодорхойлогддог. Үүнийг солих нь бас оношилгоо: туннель TCP дээгүүр босч UDP дээр үхвэл сүлжээ UDP-г шүүж байгааг нотолсон бөгөөд тэр газарт орох бүрт хэрэгтэй тохиргоог олсон.

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

Ижил профайлыг хоёр дахь сүлжээнд шалга

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

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

Сүүлийн команд илрүүлж буй ялгааг хадгалах нь зүйтэй: профайл холбогдсон туннель мэдээлж болох боловч доторх чиглүүлэлт буруу байж болох бөгөөд энэ нь "VPN асаалттай ч юу ч ажиллахгүй байна" гэсэн байдал үүсгэдэг бөгөөд энэ нь өөр нийтлэл юм. Засвараас хойш туннелийн төрөл өөрчлөгдсөн бол профайл таны шалгасан профайл биш.

Дараа нь олдсоныг дараагийн хүн харах газарт бич. "Энэ газарт корпорацийн профайлд TCP 443 хэрэгтэй; UDP 500-ыг зочид буудал шүүдэг" гэдэг нь хамт олон үйлдэл хийж болох өгүүлбэр юм. "Зочид буудалд VPN тогтворгүй" гэдэг нь тийм биш бөгөөд ирэх сард мөн тэр нэг цагийг дахин үрэх баталгаа болно.