Како да го проверите статусот на VPN без ping на Android, iOS и Windows

Ping докажува само дека еден домаќин одговорил, а не дека тунелот е активен. Прашајте ги API-јата за статус на Android, iOS и Windows, потоа проверете ја рутата што на вашата апликација навистина ѝ треба.

Ping кон 192.0.2.10 ви кажува само дека една адреса одговорила на ICMP ехо, и ништо повеќе. На мрежа без тунел може сепак да успее, бидејќи адресата може да е на локалната подмрежа; со здрав тунел може да не успее, бидејќи серверот го отфрла ICMP додека служи HTTPS. Проверката што му е потребна на вашата скрипта е барање за статус на платформата плус тест на рутата до дестинацијата што ја користи апликацијата. Третирајте ги како две одделни полиња, никогаш како еден булов израз.

Што всушност докажува одговорот на ехо

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 записот. Отворете ја портата на услугата и барајте апликациски одговор наместо само ракување. Чувајте го секое набљудување во свое поле во дневникот.

На Linux машина со dig и curl, три команди покриваат разрешување, рута и самата услуга. Извршете ги со кренат тунел и повторно со спуштен:

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-то на платформата и тестот на рутата одговараат на вистинското прашање.

Поврзани статии