Пощата стига до сървъра без 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 заявка, докато сте прекъснати, и журнала на сървъра за отхвърлена или приета сесия. Ако сървърът отказва, но клиентът все още прави опит, правилото на сървъра работи, а правилото на клиента липсва. Ако клиентът не прави опит, но сървърът все още приема други клиенти, границата е точно там, където сте я поставили.

Запишете собственика на налагането, адреса на източника, който сървърът действително вижда, и използвания тестов акаунт. Следващата промяна на мрежата или прокси може да премести този източник, а бележка, назоваваща наблюдаваната стойност, се проверява по-бързо от още един кръг догадки.