VPN підключено, але IMAP не синхронізується? Перевірте ці три рівні

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

Міф: одне з'єднання означає один вхід

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

Саме в цій прогалині насправді живе більшість звітів «IMAP не працює через VPN».

Три стани IMAP і де клієнти застрягають

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

Клієнт, який успішно автентифікується, а потім не може вибрати налаштовану теку, виглядатиме як збій синхронізації, хоча сервер поводиться правильно. Перейменовані теки, провайдер, який по-іншому зіставляє «вхідні», або відсутні права доступу — усе це закінчується тут. Позначена відповідь NO від сервера є доказом, і це не та сама відповідь, що відмова в паролі.

TLS передує розмові IMAP

За неявного TLS на порту 993 рукостискання TLS завершується до надсилання будь-якої команди IMAP, тому проблема із сертифікатом дає помилку, у якій згадується довіра, а не пошта. Ім'я хоста пошти має перевірятися за сертифікатом так само, як ім'я вебхоста; тунель, що зберігає трафік, не робить недійсний сертифікат дійсним.

Текст помилки розділяє випадки. Тайм-аут з'єднання означає, що SYN так і не завершився. Помилка TLS означає, що TCP-з'єднання працювало, а рукостискання — ні. Відповідь IMAP NO або BAD означає, що обидва кроки вдалися, а рівень протоколу щось відхилив. Запишіть, який із них ви бачили, перш ніж змінювати будь-яке налаштування.

Кешована пошта нічого не доводить

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

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

Надсилання і вебпошта — різні протоколи

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

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

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