Как обеспечить доступ мобильному телефону к Exchange в локальной сети, не используя vpn?

Question

[podvox23]

Доступ к нашему серверу Exchange открыт только внутри локальной сети. Мобильные клиенты стучатся к нему внутри VPN по протоколу IMAP. Но есть у нас один сотрудник, которому можно все, он отказывается настраивать VPN на своем телефоне.
Какие существуют способы дать доступ к Exchange мобильному телефону с ios, не устанавливая на него никаких приложений и не используя vpn? Не хотелось бы пробрасывать порты почты в интернет ради одного человека.

Answer 1

[Sergey Ryzhkin]

Не хотелось бы пробрасывать порты почты в интернет

Тогда никак.

Answer 2

[Alexey Dmitriev]

1. Проброс портов (DNAT).
2. Load balancer типа Haproxy.
3. Сервер клиентского доступа (Client Access role) Exchange

Предполагаю, что если вы спрашиваете о таких банальных вещах - знаний у вас не хватает и я бы вам не советовал выпускать exchange наружу любым из способов, если вы и ваша компания не хотите нарываться на проблемы типа https://www.microsoft.com/security/blog/2021/03/02...

Comments

[Максим Гришин]

А разве haproxy от взлома exchange спасал?

[Alexey Dmitriev]

Максим Гришин, а разве я что-то говорил про спасение от взлома?

Answer 3

[salavec]

Создай А запись в днс согласно внешнему имени на локальный ip серврера или DAG если используется

Comments

[DevMan]

и как это поможет для доступа извне?

[salavec]

не дочитал вопрос...
Можно решить следующими способами
1. VPN - отпадает, так как сотрудник отказывается
2. Умный dst-nat на шлюзе, все зависит от того какой шлюз используется
3. в exchange есть возможность контролировать MAPI для всех и каждого в отдельности
От себя скажу что в Вашем случае лучше использовать 3 вариант.

Answer 4

[Mnemonic0]

Задача: дать дать доступ к Exchange снаружи без VPN c IOS без проброса портов.
Ответ: никак

Захотите предоставить доступ. Вариантов несколько:
Доступ в браузере через OWA - DNS,NAT
Доступ через IMAP - NAT
Полноценное конфигурирование с autodiscover,без всякого старья аля IMAP/POP3 - DNS, NAT, серты

Предоставить доступ только с определённого устройства:
Разрешаем использовать только определённую версию IOS
Запрещаем использовать ActiveSync для всех, кроме данного пользователя
Запрещаем использовать OWA для всех, кроме данного пользователя

Answer 5

[Николай]

Мысль такая: берём у провайдера IPv6, у того, кто хочет подключаться без VPN, тоже ставится IPv6 (хорошо, если у него оператор МТС, иначе без VPN не обойтись), и он подключается к хосту с Exchange или какими-то другими локальными сервисами. Для ограничения доступа можно перед хостом поставить firewall, блокирующий подключения к Exchange. Перед подключением клиент выполняет какое-то действие, требующее аутентификации (например, обращается по HTTPS ссылке с указанным сертификатом или логином и паролем, или заходит по SSH с определённым ключом, просто заходит, не вводит какую-то команду), можно и port knocking'ом просто обратиться, (хотя это уже не так безопасно, если кто-то может просмотреть трафик клиента), и по этому действию с адреса клиента на определённое время разрешается доступ к сервисам.
Хотя можно и просто порты пробросить, и не использовать IPv6, с контролем по такому же принципу (по умолчанию доступ закрыт, по какому-то действию с аутентификацией на определённое время с адреса клиента открывается). Без IPv6 возможна ситуация, что у клиента shared IP, и кто-то ещё с этого же IP зайдёт, но это маловероятно.

Comments

[podvox23]

Над port knoсking думали. Этот вариант отпал, потому как требует установки отдельного приложения на ios.
А с ipv6 идея любопытная.

[Николай]

podvox23, если хочется вообще без сторонних приложений, тогда подойдёт только HTTPS ссылка.
По ней пользователь вводит логин и пароль, и получает информацию "Для вашего IP открыт доступ к такому-то сервису до определённого времени на таком-то порту нашего внешнего IP". С IPv4 схема тоже работает через открытие портов, но IPv6 ещё лучше тем, что его трудно найти сканированием адресов (если вдруг возникнет какая-то ошибка и порт останется открыт для всех, то ваш сервис будет в опасности, а на IPv6, особенно если младшая половина адреса какая-нибудь псевдослучайная, такой риск гораздо ниже).

[Николай]

podvox23, ещё самый простой вариант c IPv6, если не хочется городить ссылки и какие-то дополнительные действия на стороне клиента. Спрашиваем у пользователя, с каких операторов и из каких регионов ему нужен доступ, и открываем доступ для соответствующих диапазонов IPv6 на псевдослучайный адрес сервера (например, 2001:db8:11:44:e871:10cc:981a:bc41). Снаружи его не насканить (только если это не роутер, который может засветить адрес в трейсе). Хотя адрес может засветиться где-то в интернете, особенно если на сервере браузер запускают, но можно на сервере назначить несколько адресов, и пусть для выхода в инет используется другой адрес, а на файрволе входящие разрешены на отдельный.
Диапазоны адресов клиента могут быть, например, 2a00:1fa0::/33 (МТС Центр), 2a00:1fa0:8000::/33 (МТС Северо-Запад), 2a00:1fa0::/32 (весь МТС), или 2a00:1370::/32 (МГТС)

Answer 6

[res2001]

Используйте IMAPS, но порты все равно придется пробросить.

Answer 7

[ky0]

он отказывается настраивать VPN на своем телефоне

Напишите письмо руководителю человека, объясните варианты и причины, по которым VPN лучше проброса портов.

Comments

[podvox23]

Это и есть руководитель. Бесполезно объяснять. Думаем в сторону обратного прокси и Exchange Edge

Answer 8

[Роман Безруков]

Потыкайте для начала Remote Connectivity Analyzer для проверки соединений и/или ошибок.
iOS умеет спрашивать autodiscover и настраивать мобильного клиента.
Как Ваш Exchange ходит в интернет?
Сервис autodiscover (autodiscover.yourdomain.yourtld) как-то опубликован в интернет?
И что у Вас с ActiveSync?

Comments

[podvox23]

Порты в интернет не проброшены пока. Autodiscover в интернет не опубликован. ActiveSync не используем.
Используем IMAPS для мобильных клиентов.

Больше всего мне не нравится, что аутентификация через LDAP будет торчать в интернет. Прочитал про Exchange Edge. Он изолирован от леса AD и нас это решение вроде бы устраивает.