Pošta doseže strežnik brez VPN: kje uveljaviti pravilo

Pošta še naprej sprašuje in VPN je izklopljen, a račun se vseeno sinhronizira. Aplikacija dela tisto, za kar je bila nastavljena; nič v običajnem poštnem profilu ne pravi, da je strežnik dosegljiv le skozi tunel. To pušča dve različni zahtevi in ju je lahko zamenjati: storitev naj zavrača neposredne odjemalce ali pa Mac naj sploh ne poskusi.

Izberite zahtevo, preden izberete izdelek. Pravilo strežnika in pravilo odjemalca odpovedujeta na različnih mestih, dajeta različne dokaze in pripadata različnim lastnikom. Uporaba obeh je veljavna, ko sta obe trditvi resnični, a eno ne nadomesti drugega. Obe zahtevi sta legitimni; le nista ista kontrola.

Simptom je videti kot Mac, a puščanje je lahko na strežniku

Ko se pošta sinhronizira zunaj tunela, začnite s tem, kar strežnik sprejme. Če poštni poslušalec odgovarja na neposredno povezavo iz interneta, nobena nastavitev udobja na strani odjemalca tega dejstva ne spremeni. Mac se obnaša običajno do storitve, ki je še odprta.

Vprašajte poštnega skrbnika, kateri naslov vira vidi storitev. Prehod VPN, obratni posrednik ali razporejevalnik obremenitve lahko prevedejo naslov odjemalca, zato se nabor naslovov v konfiguraciji VPN morda ne ujema s tem, kar prispe v poštni proces. Pravilo, napisano proti napačnemu viru, blokira vse ali nikogar.

Ta odgovor pove tudi, ali storitev sploh zna razlikovati odjemalce VPN. Če vsak odjemalec prispe skozi isti naslov posrednika, sprejem na podlagi vira ne more ločiti med njimi, in zahtevo je treba premakniti na overjanje ali na stran odjemalca.

Sprejem na strežniku: zavrnite vir, ne aplikacije

Požarni zid gostitelja ali omrežja lahko omeji poštni poslušalec na odobrene obsege virov, medtem ko overjanje in TLS ostaneta nespremenjena. Pogoj pravila, ki se ujema z oddaljenimi naslovi, podomrežji ali obsegi, je običajni gradnik; natančna sintaksa pripada izdelku požarnega zidu strežnika, ne poštni aplikaciji.

To je najmočnejša meja, ko je zahteva „storitev ne sme streči neposrednim odjemalcem“. Drži tudi, če uporabnik namesti drugega poštnega odjemalca, ker se zavrnitev zgodi pred overjanjem. Prestane tudi Mac, ki ignorira svojo politiko VPN.

Njena meja je enako pomembna. Zavrnjena povezava dokazuje, da je storitev zavrnila sejo; ne dokazuje, da Mac ni poskusil. Razreševanje DNS, TCP SYN do prejšnjega razporejevalnika obremenitve in ponoven poskus po neuspehu se lahko zgodijo, preden je doseženo pravilo strežnika. Če zahteva zadeva razkritje poskusov in ne dostopa, je sprejem na strežniku le polovica nadzora.

Uveljavljanje na odjemalcu: blokirajte poskus, ne le tunela

Pravilo na strani odjemalca mora prepovedati promet, ne le začeti tunela ob odprtju pošte. Sprožilec aktivacije za poštno domeno lahko dvigne VPN ob pravem trenutku, a ne določa, kaj se zgodi, ko je tunel izklopljen ali po njegovi odpovedi.

Uporabite podprto politiko blokiranja izdelka končne točke in namerno določite njen obseg. Pravilo na ravni aplikacije pokriva vsak račun v tej poštni aplikaciji, vključno z osebnimi. Pravilo na ravni cilja mora poimenovati končne točke IMAP, pošiljanja in overjanja delovnega računa in mora delovati tudi, ko se ti naslovi spremenijo.

Pokrijte obe družini naslovov in obstoječe seje. Politika, ki blokira nove povezave IPv4, a IPv6 ali vzpostavljeni vtičnik pusti pri miru, ustvarja občasne sinhronizacije, ki so videti naključne. Spremembe omrežja in cikli spanja so del istega preskusa.

Pravila na ravni aplikacije in cilja imajo različen doseg

Blokada na ravni aplikacije je preprosta za razmislek: noben promet iz Pošte ne odide brez tunela. Je tudi groba, ker ima lahko ista aplikacija osebni račun, ki nima nič opraviti s politiko. Uporabniki to opazijo prvi in prijavijo kot pokvarjeno poštno aplikacijo.

Blokada na ravni cilja je ožja in jo je teže vzdrževati. Potrebuje celoten nabor končnih točk, ki jih račun uporablja, vključno s storitvami odkrivanja in overjanja, ter postopek za njihovo posodabljanje. Ena manjka in račun deluje na pol; vključite preveč in nepovezana pošta se ustavi.

Izberite glede na besedilo zahteve. „Ta delovni račun se ne sme povezovati neposredno“ kaže na obseg cilja. „Ta Mac ne sme poganjati pošte zunaj VPN“ upravičuje širše pravilo aplikacije, če lastnik sprejme stranski učinek za osebni račun.

Preizkusite zavrnitev in odsotnost ločeno

Z namenskim preskusnim računom se povežite prek VPN in potrdite običajno delovanje. Nato se odklopite in preizkusite dvakrat: enkrat, ali strežnik zavrača prijavo, in enkrat, ali Mac sploh poskusi povezavo. To so različna opažanja in pripadajo različnim dnevnikom.

Opazujte dokaze na strani odjemalca za SYN ali poizvedbo DNS, ko ste odklopljeni, in dnevnik strežnika za zavrnjeno ali sprejeto sejo. Če strežnik zavrača, a odjemalec še vedno poskuša, pravilo strežnika deluje in pravilo odjemalca manjka. Če odjemalec ne poskuša, a strežnik še vedno sprejema druge odjemalce, je meja točno tam, kamor ste jo postavili.

Zapišite lastnika uveljavljanja, naslov vira, ki ga strežnik resnično vidi, in uporabljeni preskusni račun. Naslednja sprememba omrežja ali posrednika lahko ta vir premakne, in opomba, ki poimenuje opaženo vrednost, se preveri hitreje kot še en krog ugibanja.