Always-On и блокирањето без VPN се две поставки и вклучувањето на едната не ја вклучува другата. Вистинскиот пар зависи од тоа чиј е уредот, кои апликации ги покрива тунелот и што се случува пред отклучување.

Два прекинувачи со различни ветувања

Always-On ветува постојаност и ја рестартира услугата кога ќе падне; блокирањето ветува ограничување: без тунел покриениот сообраќај нема излез.

Третиот фактор е опфатот по апликација, кој им припаѓа на клиентот или на политиката за управување, а не на двата системски прекинувачи; блокирање без одлука за опфатот дава политика поширока или потесна од барањето.

Прва одлука: управуван уред или корисничка поставка?

На управуван уред политиката ги држи Always-On и заклучувањето, а локалниот прекинувач може да недостасува; сменете го барањето во политиката, не на уредот.

На личен уред корисникот одлучува дали прифаќа работа без мрежа кога нема тунел; блокирањето е замена за достапност и прекинувач што недостасува не е оправдување за root.

Опфатот е по профил, не по уред: Android дозволува еден активен VPN по кориснички профил.

Блокирањето во работниот профил не кажува ништо за личната страна и тестирањето на еден контекст не го потврдува другиот.

Втора одлука: сè блокирано или некои апликации исклучени?

Исклучоците по апликација во режим на блокирање се разбираат обратно: според Android исклучените апликации можат да ја загубат врската наместо тивко да ја користат обичната мрежа, па исклучувањето не е дозвола за интернет.

Одлучете свесно: блокирајте го целиот покриен сообраќај и прифатете дека исклучените апликации остануваат во мрак, или исклучете го блокирањето и прифатете резервен пат; ако една апликација мора секогаш да има врска, блокирањето е погрешен алат.

Трета одлука: што се случува пред отклучување и на портал?

Кај повеќето клиенти тунелот не е кренат додека корисникот не го отклучи уредот, па првите мигови по подигањето се празнина, а не дефект; потврдете го тоа за клиентот што го поставувате.

Captive порталите се другиот раб: хотелска или аеродромска мрежа бара неавтентифицирана сесија на прелистувач и тврдото блокирање може да го оневозможи најавувањето; поддржаниот одговор е одобрен процес на опоравување со тригер, најдолго времетраење, кој го дава и проверка дека спроведувањето само се враќа.

Документацијата за Android VPN клиенти ги покрива Always-On и блокирањето, исклучоците по апликација и правилото еден VPN по профил; прочитајте ја пред да проектирате по сеќавање.

Тестирајте ја состојбата без мрежа и потоа напишете ја линијата за прифаќање

Користете безопасен сообраќај и поддржаниот тест за дефект: обична врска, губење на тунелот, опоравување и рестарт пред отклучување, и запишете дали апликацијата блокирала како што треба.

Проверете го ресурсот и resolver-от, не иконата, и одделно тестирајте уред зад телефонот, бидејќи политиката на телефонот не воспоставува препраќање за hotspot клиенти.

Линијата за прифаќање е конкретна и проверлива: саканата апликација во саканиот профил стигнува до одобрениот тунел и останува во бараната блокирана состојба кога не може. Пред да ја потпишете:

  • Always-On и блокирањето се поставени таму каде платформата ги поддржува и сопственикот на секоја поставка е познат.
  • Опфатот на апликациите е намерен и потврдивте што се случува со исклучените апликации во режим на блокирање.
  • Празнината пред отклучување и процесот за captive портал се одлучени, а не откриени.
  • Тестот за дефект е извршен на класата уреди што навистина ја поставувате.

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