Always-on VPN ба kill switch: та яг юуг асаасан бэ?

Always-on ба kill switch нэг тохиргооны дэлгэц дээр хоёр мөрийн зайтай байдаг тул хүмүүс тэдгээрийг нэг функцийн хоёр нэр гэж уншдаг. Тэд тийм биш. Always-on бол дахин холбогдох бодлого: ачаалах үед туннелийг эхлүүлэх, гацалт эсвэл сүлжээ солигдсоны дараа буцааж босгох, бүтэлгүйтэж байх хугацаанд дахин оролдох. Kill switch бол урсгалын бодлого: туннель унасан үед аль пакет машинаас гарч болохыг тодорхойлно. Эхнийхийг хоёрдугааргүйгээр асааж болох бөгөөд ихэнх платформ дээр анхдагч үр дүн тэр завсарт урсгалыг гаргасаар байдаг.

Шалгалт 1: блок нь тусдаа унтраалга мөн үү?

Android 10 ба түүнээс хойшхи хувилбарт хадгалсан VPN профайл арааны дүрсний ард хоёр бие даасан унтраалга нээдэг: Always-on VPN ба Block connections without VPN. Зөвхөн хоёр дахь нь kill switch. Зөвхөн always-on байхад туннель тасарсны дараа үнэхээр буцаж ирдэг бөгөөд хүсэлтийн дунд байгаа аль ч апп тэр хүртэл Wi-Fi эсвэл мобайл өгөгдлөөр сүлжээнд хүрч чадна.

Удирдлагатай төхөөрөмжүүд бодлогын API-д ижил хуваалтыг хадгалдаг. setAlwaysOnVpnPackage() багцын нэрийг, lockdownEnabled тугыг авдаг; багцыг тохируулаад тугийг false-д үлдээсэн администратор байнгын туннель барьсан, хаалттай төхөөрөмж биш. Консолын найруулга тэр ялгааг бараг ил болгодоггүй.

Төлөвийг консолоос биш, төхөөрөмжөөс уншина уу: adb shell settings get global always_on_vpn_app ба adb shell settings get global always_on_vpn_lockdown. Эхнийх нь null буцаавал платформын түвшинд ямар ч багц албадагдаагүй; хоёр дахь нь 0 буцаавал платформ юуг ч блоклохгүй байна. Android VPN гарын авлага эдгээрийг нэг горим биш, тусдаа боломж гэж тайлбарладаг.

Шалгалт 2: блок аль давхаргынх вэ?

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

Windows бол блоклодоггүй шошгын хамгийн тод жишээ. Тэнд Always On нь туннелийн тогтвортой байдлыг тодорхойлно: машины баталгаажуулалтын төхөөрөмжийн туннель, нэвтэрсэн бүртгэлийн хэрэглэгчийн туннель, профайлын XML эсвэл Add-VpnConnection-ээр тохируулагдана. Тэр профайлд туннель байхгүй үед гадагш гарч буй пакетыг зогсоох зүйл байхгүй, гадагш гаргах шүүлт анхдагчаар асаалттай биш тул Wi-Fi дээрх зөөврийн компьютер VPN унасан ч ажилласаар байна.

WireGuard мөн адил хуваагддаг, гэхдээ клиентээр. WireGuard for Windows-д туннель бүрд шүүлтийн дүрэм суулгадаг Block untunneled traffic сонголт бий; Linux хэрэгсэлд ийм унтраалга байхгүй. wg-quick AllowedIPs бичлэг бүрд маршрут, нэмээд fwmark дүрмийг нэмдэг, wg-quick down хоёуланг нь устгадаг тул физик анхдагч маршрут нэг ч пакет алдалгүй буцаж ажлаа авна.

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

Шалгалт 3: дүрс биш, завсрыг хэмж

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

Хамгийн хямд шалгалт нь туннелийг санаатайгаар зогсоож, дараа нь гарч үздэг. Туннель унасан үед curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com 200 буцаавал бодлого fail-open гэсэн үг; хугацаа дуусах эсвэл холболт татгалзагдвал ямар нэг зүйл блоклож байна. ip route get 1.1.1.1 пакетыг зөөх интерфэйсийг нэрлэдэг бөгөөд энэ нь ихэвчлэн тавиурын дүрснээс илүү мэдээлэлтэй, systemctl status wg-quick@wg0 интерфэйс цэвэр устгагдсан эсэхийг харуулна.

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

Шалгалт 4: түгжихээс өмнө үл хамаарах зүйлсийг шийд

Хоёр үл хамаарах зүйл бүтцийн шинжтэй. Клиент VPN сервер рүү өөрөө хүрэх ёстой тул бүгдийг хаядаг дүрмийн багц нь хамгаалалтыг сэргээх дахин холболтыг ч саатуулна. Captive portal руу ч босоогүй туннелээр хүрэх боломжгүй тул зочид буудлын Wi-Fi дээр түгжигдсэн төхөөрөмжид порталыг нээх бичигдсэн арга хэрэгтэй, бишрүүлсэн арга биш.

Хамгийн бага хэлбэр: төгсгөлийн цэгийг зөвшөөрч, бусад бүгдийг хаяв:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

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

Шалгалт 5: юуг үнэхээр нотолсноо бич

Дөрвөн баганатай хүснэгт хөтөлж, шалгалтаар дүүргээрэй: төлөв, хүлээгдэж буй зан төлөв, ажиглагдсан зан төлөв, нотолгоо. Мөрүүд нь шалгалт 3-ын шилжилтүүд дээр нэг санаатай алдаа нэмсэн. Командын гаралтаар дүүргэж чадахгүй мөр бол шалгаагүй мөр, дахин холболтын мөрийг давж ачааллын мөрөнд унадаг төхөөрөмж хангалттай түгээмэл тул нэмэлт арван минут үнэ цэнэтэй.

Үүнийг дууссан гэж хэлэхийн өмнө:

• Блоклох тохиргоо дахин холбогдох тохиргооноос тусдаа эсэхийг баталж, утгыг нь төхөөрөмжөөс унш.
• Блокыг аль давхарга хэрэгжүүлдэг - клиентийн сонголт, төхөөрөмжийн бодлого эсвэл галт хана - ба тэр давхарга хаана тохируулагддагийг мэд.
• Блокыг нотолдог нэг шалгах командыг хадгалж, шилжилтийн үед ажиллуул, дараа нь биш.
• Үл хамаарах зүйлсийн жагсаалтыг төгсгөлийн цэгийг оруулан бичиж, хэн шинэчилдгийг тэмдэглэ.
• Удирдлагатай техник хэрэгсэл дээр албадсан бодлогыг хөндөхгүй; блокыг авах нь туннелийг засахын оронд шаардлагыг өөрчилдөг.