Pošta dosáhne na server bez VPN: kde pravidlo vynutit

Pošta dál dotazuje a VPN je vypnutá, přesto se účet stále synchronizuje. Aplikace dělá to, na co byla nastavena; nic v běžném poštovním profilu neříká, že server je dostupný jen tunelem. Zůstávají dva různé požadavky a snadno se pletou: služba má odmítat přímé klienty, nebo Mac nemá vůbec zkoušet.

Vyberte požadavek dřív, než vyberete produkt. Pravidlo serveru a pravidlo klienta selhávají na různých místech, dávají různé důkazy a patří různým vlastníkům. Použít obojí je správné, když platí obě tvrzení, ale jedno nenahrazuje druhé. Oba požadavky jsou legitimní; jen to není stejná kontrola.

Příznak vypadá jako Mac, ale únik může být na serveru

Když se pošta synchronizuje mimo tunel, začněte tím, co server přijímá. Pokud poštovní posluchač odpovídá na přímé připojení z internetu, žádné klientské nastavení pohodlí tento fakt nezmění. Mac se chová normálně vůči službě, která je stále otevřená.

Zeptejte se poštovního správce, jakou zdrojovou adresu služba vidí. VPN brána, reverzní proxy nebo nástroj pro vyvažování zátěže mohou přeložit adresu klienta, takže fond adres v konfiguraci VPN nemusí odpovídat tomu, co dorazí do poštovního procesu. Pravidlo napsané proti špatnému zdroji buď zablokuje všechny, nebo nikoho.

Odpověď také řekne, zda služba dokáže VPN klienty vůbec rozlišit. Pokud každý klient přichází přes stejnou proxy adresu, přijetí podle zdroje je nemůže oddělit a požadavek se musí přesunout na autentizaci nebo na stranu klienta.

Přijetí na serveru: odmítněte zdroj, ne aplikaci

Firewall hostitele nebo sítě může omezit poštovní posluchač na schválené zdrojové rozsahy, přičemž autentizace a TLS zůstanou beze změny. Podmínka pravidla, která porovnává vzdálené adresy, podsítě nebo rozsahy, je obvyklý stavební prvek; přesná syntaxe patří produktu firewallu serveru, ne poštovní aplikaci.

To je nejsilnější hranice, když požadavek zní „služba nesmí obsluhovat přímé klienty“. Drží, i když si uživatel nainstaluje jiný poštovní klient, protože odmítnutí přichází před autentizací. Přežije i Mac, který ignoruje svou VPN politiku.

Její limit je stejně důležitý. Odmítnuté spojení dokazuje, že služba relaci odmítla; nedokazuje, že Mac se vůbec nepokusil. Překlad DNS, TCP SYN k dřívějšímu vyvažovači zátěže a opakování po selhání se mohou odehrát dřív, než je dosaženo pravidla serveru. Jestliže se požadavek týká zveřejnění pokusů, a ne přístupu, je přijetí na serveru jen polovinou kontroly.

Vynucení na klientu: blokujte pokus, ne jen tunel

Pravidlo na straně klienta musí provoz zakázat, ne jen spustit tunel při otevření pošty. Aktivační spouštěč pro poštovní doménu může VPN zvednout ve správný okamžik, ale neurčuje, co se děje, dokud tunel neběží nebo poté, co selže.

Použijte podporovanou politiku blokování produktu koncového bodu a záměrně vymezte její rozsah. Pravidlo na úrovni aplikace pokrývá každý účet v dané poštovní aplikaci, včetně osobních. Pravidlo na úrovni cíle musí pojmenovat IMAP, odesílací a autentizační koncové body pracovního účtu a musí fungovat i tehdy, když se tyto adresy změní.

Pokryjte obě rodiny adres a existující relace. Politika, která blokuje nová spojení IPv4, ale IPv6 nebo navázaný socket nechává na pokoji, vytváří přerušované synchronizace, které vypadají náhodně. Změny sítě a cykly spánku jsou součástí stejného testu.

Pravidla na úrovni aplikace a cíle mají různý dosah dopadu

Blokování na úrovni aplikace se snadno zdůvodňuje: žádný provoz z Pošty neodejde bez tunelu. Je také hrubé, protože stejná aplikace může držet osobní účet, který s politikou nemá nic společného. Uživatelé si toho všimnou první a nahlásí to jako rozbitou poštovní aplikaci.

Blokování na úrovni cíle je užší a hůř se udržuje. Potřebuje úplnou množinu koncových bodů, které účet používá, včetně služeb zjišťování a autentizace, a proces jejich aktualizace. Jedno vynecháte a účet funguje napůl; zahrnete příliš mnoho a nesouvisející pošta se zastaví.

Vybírejte podle formulace požadavku. „Tento pracovní účet se nesmí připojovat přímo“ ukazuje na rozsah cíle. „Tento Mac nesmí provozovat poštu mimo VPN“ ospravedlňuje širší pravidlo aplikace, pokud vlastník přijme vedlejší účinek na osobní účet.

Testujte odmítnutí a nepřítomnost odděleně

S vyhrazeným testovacím účtem se připojte přes VPN a potvrďte normální provoz. Potom se odpojte a testujte dvakrát: jednou, zda server odmítá přihlášení, a jednou, zda se Mac vůbec pokouší o spojení. To jsou různá pozorování a patří do různých logů.

Sledujte důkazy na straně klienta pro SYN nebo dotaz DNS, dokud jste odpojeni, a log serveru pro odmítnutou nebo přijatou relaci. Pokud server odmítá, ale klient se stále pokouší, pravidlo serveru funguje a pravidlo klienta chybí. Pokud se klient nepokouší, ale server stále přijímá jiné klienty, hranice je přesně tam, kde jste ji umístili.

Zapište vlastníka vynucení, zdrojovou adresu, kterou server skutečně vidí, a použitý testovací účet. Příští změna sítě nebo proxy může tento zdroj posunout, a poznámka pojmenovávající pozorovanou hodnotu se kontroluje rychleji než další kolo hádání.