Хэрэглэгч эхэлдэг газраас эхэл: клиентийн цонх алга, tray дэх дүрс алга болсон, хөтөч ачаалж байна уу, үгүй юу. Энэ ажиглалт дангаараа блоклолт үлдсэн эсэхийг хэлж чадахгүй. Хариулт нь аль бүрэлдэхүүн дүрмийг барьж байгаа, тэр бүрэлдэхүүн цонхтой хамт үхсэн эсэх, платформ хэрэгжилтийг апп-аас гадуур барьж байгаа эсэхээс хамаарна. Цонхноос процесс руу, дараа нь firewall руу, дараа нь бодит зам руу яв.

Эхлээд reboot хийхгүй байх; reboot ихэвчлэн нотолгоог устгадаг.

Одоо ч ажиллаж байгаа зүйлээс эхэл

Ямар ч зүйлд хүрэхээс өмнө процессын жагсаалтыг нээ. Ширээний клиент ихэвчлэн хэрэглэгчийн интерфейсийн процесс болон үйлчилгээ эсвэл демон болж хуваагддаг бөгөөд эхнийх нь унасан нь хоёр дахьыг зогсоох албагүй. Windows дээр үйлчилгээ жагсаалтад байж болно, Linux дээр unit идэвхтэй байж болно, Android дээр зөвшөөрөл өгсний дараа туннель системийн эзэмшилд байдаг. Эдгээр гурван баримтыг энэ дарааллаар унш.

Демон амьд бол туннель ч бас амьд байх магадлалтай, алга болсон цонх зөвхөн гоёл чимэглэл юм.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

Блоклолтыг аппаас биш, хэрэгжүүлэгчээс унш

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

Android үүнийг дахин өөрөөр шийддэг: lockdown-той always-on VPN нь платформын тохиргоо тул блоклолт аппын процессоос үл хамааран үргэлжилнэ, систем үйлчилгээг дахин эхлүүлж болно. Яг зан төлөвийг платформын баримт бичгээс үзээрэй, ширээний клиенттэй ижил гэж бүү бод.

Цэвэр гарцыг уналтаас ялга

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

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

Бусад хяналтыг эвдэхгүйгээр сэргээ

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

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

Нэг уналт гоожсон гэдгийн баталгаа биш. Баталгаа бол бодлого сэргийлэх ёстой байсан замаар гарч буй нь ажиглагдсан пакет, клиент унтарсан тэр мөчид баригдсан. Үүнийг санаатайгаар, хор хөнөөлгүй очих газартай туршиж, аль хэрэгжүүлэх давхарга тэссэнийг бич.

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