Poczta dociera do serwera bez VPN: gdzie egzekwować regułę

Poczta wciąż odpytuje, a VPN jest wyłączony, lecz konto nadal się synchronizuje. Aplikacja robi to, do czego została skonfigurowana; nic w zwykłym profilu poczty nie mówi, że serwer jest osiągalny tylko przez tunel. To pozostawia dwa różne wymagania i łatwo je pomylić: usługa ma odrzucać bezpośrednich klientów albo Mac nie ma w ogóle próbować.

Wybierz wymaganie, zanim wybierzesz produkt. Reguła serwera i reguła klienta zawodzą w różnych miejscach, dają różne dowody i należą do różnych właścicieli. Stosowanie obu jest słuszne, gdy oba stwierdzenia są prawdziwe, ale jedno nie zastępuje drugiego. Oba wymagania są zasadne; po prostu nie są tą samą kontrolą.

Objaw wygląda jak Mac, ale wyciekiem może być serwer

Gdy poczta synchronizuje się poza tunelem, zacznij od tego, co serwer akceptuje. Jeśli nasłuch poczty odpowiada na bezpośrednie połączenie z internetu, żadne udogodnienie po stronie klienta tego faktu nie zmienia. Mac zachowuje się normalnie wobec usługi, która wciąż jest otwarta.

Zapytaj administratora poczty, jaki adres źródłowy widzi usługa. Brama VPN, odwrotny serwer proxy lub moduł równoważenia obciążenia mogą tłumaczyć adres klienta, więc pula adresów w konfiguracji VPN może nie odpowiadać temu, co dociera do procesu poczty. Reguła napisana wobec niewłaściwego źródła albo blokuje wszystkich, albo nikogo.

Ta odpowiedź mówi też, czy usługa w ogóle potrafi odróżnić klientów VPN. Jeśli każdy klient przychodzi przez ten sam adres proxy, dopuszczanie oparte na źródle nie może ich rozdzielić, a wymaganie musi przejść na uwierzytelnianie albo na stronę klienta.

Dopuszczanie na serwerze: odrzuć źródło, nie aplikację

Zapora hosta lub sieci może ograniczyć nasłuch poczty do zatwierdzonych zakresów źródłowych, pozostawiając uwierzytelnianie i TLS bez zmian. Warunek reguły dopasowujący zdalne adresy, podsieci lub zakresy to zwykły element budulcowy; dokładna składnia należy do produktu zapory serwera, a nie do aplikacji poczty.

To najsilniejsza granica, gdy wymaganie brzmi „usługa nie może obsługiwać bezpośrednich klientów”. Utrzymuje się nawet wtedy, gdy użytkownik zainstaluje innego klienta poczty, bo odmowa następuje przed uwierzytelnianiem. Przetrwa też Maca, który ignoruje swoją politykę VPN.

Jej granica jest równie ważna. Odrzucone połączenie dowodzi, że usługa odrzuciła sesję; nie dowodzi, że Mac nie podjął próby. Rozwiązywanie DNS, TCP SYN do wcześniejszego równoważenia obciążenia i ponowna próba po niepowodzeniu mogą wszystkie wydarzyć się, zanim reguła serwera zostanie osiągnięta. Jeśli wymaganie dotyczy ujawniania prób, a nie dostępu, dopuszczanie na serwerze to tylko połowa kontroli.

Egzekwowanie na kliencie: blokuj próbę, nie tylko tunel

Reguła po stronie klienta musi zakazywać ruchu, a nie tylko uruchamiać tunel przy otwarciu poczty. Wyzwalacz aktywacji dla domeny pocztowej może podnieść VPN w odpowiednim momencie, ale nie określa, co dzieje się, gdy tunel jest wyłączony lub po jego niepowodzeniu.

Użyj obsługiwanej polityki blokowania produktu endpoint i świadomie wyznacz jej zakres. Reguła na poziomie aplikacji obejmuje każde konto w tej aplikacji poczty, także osobiste. Reguła na poziomie celu musi wymienić punkty końcowe IMAP, wysyłania i uwierzytelniania konta służbowego i musi działać dalej, gdy te adresy się zmieniają.

Obejmij obie rodziny adresów i istniejące sesje. Polityka, która blokuje nowe połączenia IPv4, a IPv6 lub ustanowione gniazdo zostawia w spokoju, daje przerywane synchronizacje, które wyglądają na losowe. Zmiany sieci i cykle uśpienia są częścią tego samego testu.

Reguły na poziomie aplikacji i celu mają różny zasięg

Blokada na poziomie aplikacji jest prosta w rozumowaniu: żaden ruch z Poczty nie wychodzi bez tunelu. Jest też brutalna, bo ta sama aplikacja może mieć konto osobiste, które nie ma nic wspólnego z polityką. Użytkownicy zauważają to pierwsi i zgłaszają jako zepsutą aplikację poczty.

Blokada na poziomie celu jest węższa i trudniejsza w utrzymaniu. Potrzebuje pełnego zestawu punktów końcowych używanych przez konto, w tym usług wykrywania i uwierzytelniania, oraz procesu ich aktualizacji. Brakuje jednego i konto działa połowicznie; dodasz za dużo i niepowiązana poczta się zatrzyma.

Wybieraj według brzmienia wymagania. „To konto służbowe nie może łączyć się bezpośrednio” wskazuje na zakres celu. „Ten Mac nie może prowadzić poczty poza VPN” uzasadnia szerszą regułę aplikacji, o ile właściciel akceptuje skutek uboczny dla konta osobistego.

Testuj odmowę i brak próby osobno

Z dedykowanym kontem testowym połącz się przez VPN i potwierdź normalne działanie. Potem rozłącz i przetestuj dwukrotnie: raz, czy serwer odrzuca logowanie, i raz, czy Mac w ogóle próbuje połączenia. To różne obserwacje i należą do różnych dzienników.

Patrz na dowody po stronie klienta na SYN lub zapytanie DNS, gdy jesteś rozłączony, oraz na dziennik serwera na sesję odrzuconą lub przyjętą. Jeśli serwer odrzuca, ale klient nadal próbuje, reguła serwera działa, a reguły klienta brakuje. Jeśli klient nie próbuje, ale serwer nadal przyjmuje innych klientów, granica jest dokładnie tam, gdzie ją umieściłeś.

Zapisz właściciela egzekwowania, adres źródłowy, który serwer naprawdę widzi, i użyte konto testowe. Następna zmiana sieci lub proxy może przesunąć to źródło, a notatka nazywająca zaobserwowaną wartość sprawdza się szybciej niż kolejna runda zgadywania.