Pošta stiže do servera bez VPN-a: gdje primijeniti pravilo

Pošta stalno provjerava, a VPN je isključen, ali se račun i dalje sinhronizuje. Aplikacija radi ono za šta je konfigurisana; ništa u normalnom poštanskom profilu ne kaže da je server dostupan samo kroz tunel. To ostavlja dva različita zahtjeva i lako ih je pomiješati: usluga treba da odbije direktne klijente ili Mac nikada ne treba da pokuša.

Odaberite zahtjev prije nego što odaberete proizvod. Serversko pravilo i klijentsko pravilo padaju na različitim mjestima, daju različite dokaze i pripadaju različitim vlasnicima. Primjena oba je valjana kada su obje tvrdnje tačne, ali jedno nije zamjena za drugo. Oba zahtjeva su legitimni; samo nisu ista kontrola.

Simptom izgleda kao Mac, ali curenje može biti na serveru

Kada se pošta sinhronizuje izvan tunela, počnite od onoga što server prihvata. Ako poštanski slušalac odgovara na direktnu vezu s interneta, nijedna klijentska postavka udobnosti ne mijenja tu činjenicu. Mac se ponaša normalno prema usluzi koja je još otvorena.

Pitajte poštanskog administratora koju izvornu adresu usluga vidi. VPN gejtvej, obrnuti proksi ili balanser opterećenja mogu prevesti adresu klijenta, pa se skup adresa u VPN konfiguraciji možda ne poklapa s onim što stigne do poštanskog procesa. Pravilo napisano protiv pogrešnog izvora ili blokira sve ili ne blokira nikoga.

Taj odgovor takođe kaže može li usluga uopšte razlikovati VPN klijente. Ako svaki klijent dolazi kroz istu proksi adresu, prijem zasnovan na izvoru ne može ih razdvojiti i zahtjev se mora premjestiti na autentifikaciju ili na klijentsku stranu.

Prijem na serveru: odbijte izvor, ne aplikaciju

Host ili mrežni firewall može ograničiti poštanski slušalac na odobrene izvorne raspone, ostavljajući autentifikaciju i TLS nepromijenjenima. Uslov pravila koji poklapa udaljene adrese, podmreže ili raspone uobičajen je gradivni blok; tačna sintaksa pripada serverskom firewall proizvodu, ne poštanskoj aplikaciji.

To je najjača granica kada zahtjev glasi „usluga ne smije posluživati direktne klijente“. Ona vrijedi čak i ako korisnik instalira drugi poštanski klijent, jer odbijanje dolazi prije autentifikacije. Ona takođe preživi Mac koji ignoriše svoju VPN politiku.

Njena granica je jednako važna. Odbijena veza dokazuje da je usluga odbila sesiju; ne dokazuje da Mac nije pokušao. DNS razrješavanje, TCP SYN prema ranijem balanseru opterećenja i ponovni pokušaj nakon neuspjeha mogu se svi dogoditi prije nego se dosegne serversko pravilo. Ako se zahtjev tiče otkrivanja pokušaja, a ne pristupa, prijem na serveru je samo pola kontrole.

Sprovođenje na klijentu: blokirajte pokušaj, ne samo tunel

Klijentsko pravilo mora zabraniti saobraćaj, a ne samo pokrenuti tunel kada se pošta otvori. Aktivacijski okidač za poštanski domen može podići VPN u pravom trenutku, ali ne određuje šta se dešava dok je tunel pao ili nakon što ne uspije.

Koristite podržanu politiku blokiranja proizvoda za krajnje tačke i namjerno odredite njen obim. Pravilo na nivou aplikacije pokriva svaki račun u toj poštanskoj aplikaciji, uključujući lične. Pravilo na nivou odredišta mora imenovati IMAP, slanje i autentifikacijske krajnje tačke radnog računa i mora nastaviti raditi kada se te adrese promijene.

Pokrijte obje adresne familije i postojeće sesije. Politika koja blokira nove IPv4 veze dok IPv6 ili uspostavljeni socket ostavlja na miru proizvodi isprekidane sinhronizacije koje izgledaju slučajno. Mrežne promjene i ciklusi spavanja dio su istog testa.

Pravila na nivou aplikacije i odredišta imaju različit obim dejstva

Blokada na nivou aplikacije jednostavna je za razmišljanje: nijedan saobraćaj iz Pošte ne izlazi bez tunela. Ona je i gruba, jer ista aplikacija može držati lični račun koji nema nikakve veze s politikom. Korisnici to prvi primijete i prijave kao pokvarenu poštansku aplikaciju.

Blokada na nivou odredišta uža je i teža za održavanje. Potreban joj je kompletan skup krajnjih tačaka koje račun koristi, uključujući usluge otkrivanja i autentifikacije, i proces za njihovo ažuriranje. Propuštite jednu i račun radi napola; uključite previše i nepovezana pošta staje.

Odaberite prema formulaciji zahtjeva. „Ovaj radni račun ne smije se povezivati direktno“ ukazuje na obim odredišta. „Ovaj Mac ne smije voditi poštu izvan VPN-a“ opravdava šire pravilo aplikacije, pod uslovom da vlasnik prihvati nuspojavu za lični račun.

Testirajte odbijanje i odsustvo odvojeno

S namjenskim testnim računom povežite se kroz VPN i potvrdite normalan rad. Zatim se odspojite i testirajte dvaput: jednom da vidite odbija li server prijavu, i jednom da vidite pokušava li Mac uopšte vezu. To su različita zapažanja i pripadaju različitim dnevnicima.

Gledajte klijentske dokaze za SYN ili DNS upit dok ste odspojeni i serverski dnevnik za odbijenu ili prihvaćenu sesiju. Ako server odbija ali klijent još pokušava, serversko pravilo radi a klijentsko nedostaje. Ako klijent ne pokušava ali server još prihvata druge klijente, granica je tačno tamo gdje ste je postavili.

Zapišite vlasnika sprovođenja, izvornu adresu koju server zaista vidi i korišteni testni račun. Sljedeća mrežna ili proksi promjena može pomjeriti taj izvor, a bilješka koja imenuje zapaženu vrijednost brže se provjerava od još jedne runde nagađanja.