Android, iOS, Windows дээр pingгүйгээр VPN-ийн төлөвийг хэрхэн шалгах вэ

ping нь зөвхөн нэг хост хариулсан гэдгийг баталдаг бөгөөд туннель ажиллаж байгааг биш. Android, iOS, Windows-ийн төлөвийн API-аас асууж, дараа нь апп-д тань үнэхээр хэрэгтэй замналыг шалгаарай.

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

Цуурайн хариу үнэндээ юуг баталдаг вэ

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

Та үнэндээ мэдэхийг хүсч буй зүйл бол тодорхой үйлчилгээ апп-ын явдаг замд ашиглагдах боломжтой эсэх юм. Апп-ын дууддаг хост, портыг сонгоод, апп-ын түвшинд хариу шаардаарай.

Хүртээмж ба туннелийн төлөв нь өөр өөр баримтууд бөгөөд нэг нь үнэн байхад нөгөө нь худал байж болно. Тэднийг тусгаар байлгавал алдаа хэнийх болохыг мэдэж болно. Нэг шалгалтад нэгтгэвэл хэн ч чиглүүлж чадахгүй тикет үүсдэг.

Android-оос ping биш, тээврийг асуу

Android төлөвийн асуултад ConnectivityManager-ээр шууд хариулдаг. Идэвхтэй сүлжээний боломжууд VPN тээврийн тугийг агуулдаг бөгөөд урсгал VPN интерфейсээр чиглэгдэх үед тогтоогддог. Энэ дуудлага нь локал, хямд бөгөөд ямар нэг алслагдсан хост хариулж байгаа эсэхээс хамааралгүй.

Энэ Java хувилбар нь идэвхтэй сүлжээ байхгүй үед үл хамаарах зүйл шидэхийн оронд false буцаана. Идэвхтэй сүлжээг уншдаг тул хэрэглэгчийн Тохиргоонд сонгосон профайлыг илэрхийлдэг.

ConnectivityManager cm = (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE);
NetworkCapabilities caps = cm.getNetworkCapabilities(cm.getActiveNetwork());
boolean tunnel = caps != null && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);

Өөрчлөлтийн мэдэгдэлд таймераар асуухын оронд NetworkCallback бүртгүүлээрэй. Үүнийг VpnService.prepare-тэй андуурч болохгүй, тэр нь зөвхөн хэрэглэгч VPN-д зөвшөөрөл өгсөн эсэхийг мэдээлдэг, пакетууд урсаж байгаа эсэхийг биш. Цуцлалт VpnService.onRevoke-оор ирдэг ч Тохиргоонд профайлыг мартах нь ямар ч нэвтрүүлэлт үүсгэдэггүй.

iOS: интерфейсийн нэрс нь эвристик, гэрээ биш

Олон iOS хэсгүүд прокси тохиргоог шалгаж, __SCOPED__ толь бичгийг олоод tap, tun, utun2, ppp эсвэл ipsec зэрэг интерфейсийн түлхүүрүүдийг хайдаг. Энэ арга нь нэрлэх уламжлал, баримтжуулсан баталгаа биш тул интерфейсийг өөрчилсөн OS шинэчлэлт үүнийг эвдэж болно. Мөн туннелээс урт насалдаг хуучирсан бичлэгүүдэд true мэдээлэх хандлагатай.

Тохиргоо таны апп-д байвал оронд нь NEVPNManager жинхэнэ төлөв өгнө. Энэ нь таны апп-ын эхлүүлсэн туннелийг дүрсэлдэг; апп тус бүрийн VPN-тэй үед бусад апп бүрэн гадуур байж болно.

Төлөвийг уншихаас өмнө тохиргоог дахин ачаална уу, учир нь туннель өгсөх, буурах үед утга өөрчлөгддөг:

let manager = NEVPNManager.shared()
manager.loadFromPreferences { error in
    let up = manager.connection.status == .connected
    print(up)
}

Платформын төлөвийн туг нь урсгал түншдээ хүрдэг гэдгийг батлахгүй. Яг тэр завсрыг замналын тест нөхдөг тул дэмжлэгт нэг логик утга хангалтгүй.

Windows профайлууд жинхэнэ төлөвийн талбарыг ил гаргадаг

Windows нь VPN профайлуудыг адаптеруудаас тусдаа хянадаг бөгөөд Get-VpnConnection нь мэддэг профайл бүрт ConnectionStatus-ыг ил гаргадаг. Windows клиент эсвэл бэлтгэлийн багцаар үүсгэсэн профайлууд энд харагдана. Энэ cmdlet нь ерөнхий туннель илрүүлэгч биш.

Нэрлэсэн профайлын талбарыг уншаад, профайл бүх хэрэглэгчийнх бол -AllUserConnection нэмнэ үү:

Get-VpnConnection -Name "Fabrikam" | Select-Object Name, ConnectionStatus, ServerAddress

Гуравдагч талын клиентүүд туннель ажиллаж байсан ч энэ cmdlet-д үл үзэгдэх хэвээр байдаг тул хоосон үр дүн нь тодорхойгүй гэсэн үг, салгагдсан гэсэн үг биш. Адаптерын жагсаалт ч адил төөрөгдүүлдэг: нийлүүлэгчийн адаптер идэвхгүй байхдаа ч үлдэж болно, зарим адаптер зөвхөн сессийн үеэр байдаг. Windows-ийн эзэмшлийн профайлд rasdial салбарлаж болох гарах кодыг мэдээлдэг. Энэ бүгд локал итгэл үнэмшлийг дүрсэлдэг, түншийн хүртээмжийг биш.

Төлөв нэмэх замнал: хоёр хэсэгтэй шалгалт

Холбогдсон профайл пакетууд хаашаа явдгийн талаар юу ч хэлдэггүй. Хуваагдсан туннель нь туннелийг ажиллуулж байхдаа тань чухал очих газрыг хасч болно. always-on профайлууд үхсэн сервертэй ч холбогдсон хэвээр байдаг, туннель унахад kill switch урсгалыг санаатайгаар блоклодог.

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

ip route get 192.0.2.10
resolvectl query intranet.example.test

Клиент таны хяналтаас гадуур байвал хоёр үр дүнг бүртгэж, хэв маяг нь давхаргыг зааж өгөхийг зөвшөөр. Холбогдсон ба бүтэлгүй замналын тест нь хуваагдсан туннель, DNS эсвэл бодлогыг илтгэнэ. Салгагдсан ба ажиллаж буй замналын тест нь урсгалыг өөр зам зөөж байгааг илэрхийлнэ.

Дарааллаар гүйцэтгэж болох тест

Сүлжээний ямар нэг төлөвийг өөрчлөхөөс өмнө эхлээд платформын төлөвийг бүртгээрэй. Хостын нэрийг шийдэж, хаягийн бүлгийг тэмдэглээрэй, учир нь AAAA бичлэг A бичлэгээс өөр замаар явж болно. Үйлчилгээний портыг нээж, зөвхөн гар барилт биш апп-ын хариу шаардаарай. Ажиглалт бүрийг өөрийн логоны талбарт хадгал.

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

dig +short intranet.example.test
ip route get 198.51.100.20
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 https://intranet.example.test/health

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

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