Пошта доходить до сервера без VPN: де застосовувати правило

Пошта продовжує опитувати, VPN вимкнено, але обліковий запис усе ще синхронізується. Застосунок робить те, для чого налаштований; ніщо у звичайному поштовому профілі не каже, що сервер доступний лише через тунель. Це залишає дві різні вимоги, і їх легко змішати: служба має відмовляти прямим клієнтам, або Mac не повинен робити спроби взагалі.

Виберіть вимогу до вибору продукту. Правило сервера і правило клієнта зазнають невдачі в різних місцях, дають різні докази й належать різним власникам. Застосовувати обидва доречно, коли обидва твердження правдиві, але одне не замінює інше. Обидві вимоги законні; просто це не той самий контроль.

Симптом виглядає як Mac, але витік може бути на сервері

Коли пошта синхронізується поза тунелем, почніть із того, що сервер приймає. Якщо поштовий слухач відповідає на пряме з’єднання з інтернету, жодне клієнтське налаштування зручності цього факту не змінює. Mac поводиться звично щодо служби, яка ще відкрита.

Запитайте поштового адміністратора, яку адресу джерела бачить служба. Шлюз VPN, зворотний проксі або балансувальник навантаження можуть транслювати адресу клієнта, тож пул адрес у конфігурації VPN може не збігатися з тим, що надходить до поштового процесу. Правило, написане проти неправильного джерела, або блокує всіх, або нікого.

Ця відповідь також каже, чи служба взагалі вміє розрізняти клієнтів VPN. Якщо кожен клієнт надходить через ту саму адресу проксі, допуск за джерелом не може їх розділити, і вимогу слід перенести на автентифікацію або на бік клієнта.

Допуск на сервері: відмовляйте джерелу, а не застосунку

Міжмережевий екран хоста або мережі може обмежити поштовий слухач затвердженими діапазонами джерел, залишивши автентифікацію та TLS без змін. Умова правила, що зіставляє віддалені адреси, підмережі або діапазони, — звичайний будівельний блок; точний синтаксис належить продукту міжмережевого екрана сервера, а не поштовому застосунку.

Це найміцніша межа, коли вимога звучить як «служба не повинна обслуговувати прямих клієнтів». Вона тримається, навіть якщо користувач встановить інший поштовий клієнт, бо відмова відбувається до автентифікації. Вона також переживає Mac, який ігнорує свою політику VPN.

Її межа не менш важлива. Відхилене з’єднання доводить, що служба відмовила в сеансі; воно не доводить, що Mac не намагався. Розв’язання DNS, TCP SYN до попереднього балансувальника навантаження й повторна спроба після збою — усе це може статися до того, як буде досягнуто правило сервера. Якщо вимога стосується розкриття спроб, а не доступу, допуск на сервері — лише половина контролю.

Примус на клієнті: блокуйте спробу, а не лише тунель

Правило на боці клієнта має забороняти трафік, а не лише запускати тунель під час відкриття пошти. Тригер активації для поштового домену може підняти VPN у потрібний момент, але він не визначає, що відбувається, поки тунель вимкнений або після його збою.

Використовуйте підтримувану політику блокування продукту кінцевої точки й навмисно визначте її обсяг. Правило рівня застосунку охоплює кожен обліковий запис у цьому поштовому застосунку, зокрема особисті. Правило рівня призначення має назвати кінцеві точки IMAP, надсилання й автентифікації робочого облікового запису, і воно має далі працювати, коли ці адреси змінюються.

Охопіть обидві родини адрес і наявні сеанси. Політика, що блокує нові з’єднання IPv4, але залишає IPv6 або встановлений сокет без уваги, дає переривчасті синхронізації, які здаються випадковими. Зміни мережі й цикли сну — частина того самого тесту.

Правила рівня застосунку й рівня призначення мають різний обсяг впливу

Блокування рівня застосунку легко зрозуміти: без тунелю з Пошти не виходить жодного трафіку. Воно також грубе, бо в тому самому застосунку може бути особистий обліковий запис, який не має нічого спільного з політикою. Користувачі помічають це першими й повідомляють як про зламаний поштовий застосунок.

Блокування рівня призначення вужче й складніше в обслуговуванні. Йому потрібен повний набір кінцевих точок, які використовує обліковий запис, зокрема служби виявлення й автентифікації, та процес їх оновлення. Однієї бракує — обліковий запис працює наполовину; увімкніть забагато — не пов’язана пошта зупиниться.

Вибирайте за формулюванням вимоги. «Цей робочий обліковий запис не повинен з’єднуватися напряму» вказує на обсяг призначення. «Цей Mac не повинен запускати пошту поза VPN» виправдовує ширше правило застосунку, якщо власник приймає побічний ефект для особистого облікового запису.

Перевіряйте відмову й відсутність спроби окремо

З виділеним тестовим обліковим записом підключіться через VPN і підтвердьте нормальну роботу. Потім відключіться й перевірте двічі: один раз — чи відмовляє сервер у вході, і один раз — чи Mac узагалі намагається встановити з’єднання. Це різні спостереження, і вони належать до різних журналів.

Стежте за доказами на боці клієнта щодо SYN або DNS-запиту, поки ви відключені, і за журналом сервера щодо відхиленого чи прийнятого сеансу. Якщо сервер відмовляє, але клієнт усе ще намагається, правило сервера працює, а правила клієнта немає. Якщо клієнт не намагається, але сервер усе ще приймає інших клієнтів, межа саме там, де ви її поставили.

Запишіть власника примусу, адресу джерела, яку сервер справді бачить, і використаний тестовий обліковий запис. Наступна зміна мережі або проксі може зсунути це джерело, а нотатка з назвою спостереженого значення перевіряється швидше, ніж ще одне коло здогадів.