Пошта працягвае прыходзіць на тэлефон, які ніколі не паказваў значок 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, аўтэнтыфікацыю і кантроль доступу на месцы, а не лічыце адсутнасць тунеля доказам таго, што пошта не шыфруецца.

Запіс падтрымкі павінен называць прадукт пошты, канчатковы пункт, абсяг уліковага запісу і палітыку злучэння. Аднолькавыя паролі не з'яўляюцца доказам ні адносна аднаго з гэтых чатырох, і гэта самая частая прычына, чаму заяўка змяшчае чатыры абзацы і ніводнага факта.

Падобныя артыкулы