Ինչպես ստուգել VPN-ի կարգավիճակը առանց ping-ի Android-ում, iOS-ում և Windows-ում

192.0.2.10-ին ping անելը ձեզ ասում է միայն, որ մեկ հասցե պատասխանել է ICMP արձագանքին, և վերջ։ Առանց թունելի ցանցում այն կարող է այնուամենայնիվ հաջողվել, որովհետև հասցեն կարող է լինել տեղական ենթացանցում. առողջ թունելի դեպքում այն կարող է ձախողվել, որովհետև սերվերը դեն է նետում ICMP-ն, մինչ HTTPS է մատուցում։ Ձեր սկրիպտին անհրաժեշտ ստուգումը հարթակի կարգավիճակի հարցումն է գումարած երթուղու թեստը դեպի այն նպատակակետը, որն օգտագործում է հավելվածը։ Վերաբերվեք դրանց որպես երկու առանձին դաշտ, երբեք որպես մեկ բուլյան։

Ինչ է իրականում ապացուցում արձագանքի պատասխանը

ICMP-ն հասանելիության արձանագրություն է, որը պատկերացում չունի ինտերֆեյսների կամ թունելների մասին։ Երբ պատասխանը գալիս է, միջուկը հայտնում է, որ հոսթը պատասխանել է. այն չի հայտնում, թե որ երթուղին է տարել հարցումը և որը՝ պատասխանը։ Զտումը ազդանշանն ավելի աղմկոտ է դարձնում, քանի որ արձագանքային հարցումներն արգելափակող firewall-ը ոչինչ չի ասում իր հետևի պորտերի մասին։ Իսկ բաժանված թունելի պրոֆիլը կարող է դիտավորյալ բացառել փորձարկվող հասցեն, մինչ մնացած բոլոր նպատակակետերը աշխատում են։

Այն, ինչ դուք իրականում ուզում եք իմանալ, այն է՝ արդյոք կոնկրետ ծառայությունը օգտագործելի է այն ուղու վրա, որով անցնում է հավելվածը։ Ընտրեք այն հոսթն ու պորտը, որոնց կանչում է հավելվածը, ապա պահանջեք պատասխան հավելվածային մակարդակում։

Հասանելիությունը և թունելի վիճակը տարբեր փաստեր են, և դրանցից մեկը կարող է ճշմարիտ լինել, մինչ մյուսը կեղծ է։ Դրանք առանձին պահելը ձեզ ասում է, թե ումն է խափանումը։ Դրանք մեկ ստուգման մեջ միավորելը ստեղծում է տոմս, որը ոչ ոք չի կարող ուղղորդել։

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-ն և երթուղու թեստը պատասխանում են իրական հարցին։