Поштата продолжува да пристигнува на телефон кој никогаш не покажал икона за VPN, и природниот заклучок е дека нешто невидливо ја поминува низ тунел. Обично не е вклучено ништо невидливо. Додавањето Exchange сметка не избира порта, протокол, сертификат или рута, бидејќи сметката е идентитет на услуга, а тунелот е мрежен распоред што го поставил некој друг. Корисниот чекор е да утврдите каков распоред навистина имате, наместо да барате тунел што никогаш не постоел.

Три распореди, еден ист екран

Сите три завршуваат со појавување на поштата на уредот, а екранот со поставки изгледа исто во секој случај. Разликата е во тоа кој го конфигурирал патот и каков доказ потврдува дека постои.

ArrangementWho set it upWhat proves it
Approved public mail entryThe service owner, at the publishing layerA published endpoint reached over TLS with its own authentication
Managed app or account VPNDevice management, as explicit policyA profile binding that traffic to a VPN association
Already active tunnelAn always-on service or an earlier manual connectTunnel state plus routes and scope that include the mail destination

Јавната достапност заслужува своја реченица, бидејќи постојано се чита погрешно. Објавената поштенска услуга не е услуга без автентикација, а фактот дека поштата е достапна не кажува ништо за тоа дали е достапна останатата корпоративна мрежа. Тоа се одделни одлуки што ги носат одделни луѓе.

Што всушност може да врзе управувањето со уреди

Apple платформите поддржуваат VPN правила по апликација и по поштенски домен, а управуваната пошта на iOS или iPadOS може да носи VPN поврзување специфично за сметката. Тоа поврзување е поставка за обезбедување со вредност што некој ја избрал, и токму затоа не може да се заклучи од внесување е-адреса и лозинка во телефон.

Управувањето со Android и клиентите од трети страни имаат свои контроли за апликации и профили, и ниту една од нив не е заменлива со Apple пакетите за сметка. Политиката што постои на една платформа мора намерно да се репродуцира на друга. Таа не патува со поштенската сметка и не доаѓа затоа што истото лице се најавило на двете. Очекувањето дека овој пренос ќе се случи сам по себе стои зад голем дел од меѓуплатформските извештаи „кај мене на телефон работи“.

Идентитетот и преносот остануваат одделни

Поштенската услуга и VPN можат законски да делат директориум или давател на идентитет, и луѓето тоа заедничко најавување го читаат како доказ за заедничка сесија. Не е така. Повторениот текст на корисничкото име не покажува дека поштата апликација наследила VPN сесија, и тоа не е причина да се измислат неповрзани лозинки за секоја услуга.

Двете услуги бараат сопствена автентикација под сопствени услови. Успешната најава во поштата никогаш не треба да се третира како нешто што се лепи во VPN клиент, а кренатиот тунел не кажува ништо за тоа која сметка ќе ја прифати поштенскиот сервер. Референцата за поштенски профил на Intune е корисна илустрација овде, бидејќи VPN поврзувањето го третира како одделна поставка, а не како својство изведено од името на сметката.

Свежата синхронизација победува кеширано сандаче

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

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

Запишете што сте провериле

Ако пристапот треба да бара тунел, сопственикот треба да го потврди и дозволениот приватен пат и однесувањето без него. Ако услугата е намерно објавена, задржете ја нејзината TLS валидација, автентикација и контроли за пристап на место, наместо отсуството на тунел да го сметате за доказ дека поштата не е шифрирана.

Записот за поддршка треба да ги наведе производот за пошта, крајната точка, опсегот на сметката и политиката за врска. Истите лозинки не се доказ за ниту една од тие четири, и тоа е најчестата причина зошто тикетот содржи четири параграфи и никакви факти.

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