Post jõuab serverini ilma VPN-ita: kus reeglit rakendada

Post jätkab küsitlemist ja VPN on maas, kuid konto sünkroonib endiselt. Rakendus teeb seda, milleks see seadistati; ükski tavaline meiliprofiil ei ütle, et server on kättesaadav ainult tunnelis. Nii jääb kaks erinevat nõuet, mida on lihtne segi ajada: teenus peaks keelduma otseklientidest või ei peaks Mac üldse katset tegema.

Valige nõue enne toote valimist. Serverireegel ja kliendireegel ei täida oma ülesannet erinevates kohtades, annavad erinevaid tõendeid ja kuuluvad erinevatele omanikele. Mõlema rakendamine on õige siis, kui mõlemad väited peavad paika, kuid üks ei asenda teist. Mõlemad nõuded on legitiimsed; need lihtsalt ei ole sama kontroll.

Sümptom näeb välja nagu Mac, aga leke võib olla serveris

Kui post sünkroonib väljaspool tunnelit, alustage sellest, mida server vastu võtab. Kui meilikuulaja vastab internetist tulevale otseühendusele, ei muuda ükski kliendipoolne mugavusseade seda fakti. Mac käitub tavaliselt teenuse suhtes, mis on endiselt avatud.

Küsige meiliadministraatorilt, millist lähteaadressi teenus näeb. VPN-lüüs, pöördproksi või koormustasakaalustaja võib kliendi aadressi tõlkida, nii et VPN-i seadistuses olev aadressikogum ei pruugi ühtida sellega, mis meiliprotsessini jõuab. Vale allika vastu kirjutatud reegel blokeerib kas kõiki või mitte kedagi.

See vastus ütleb ka, kas teenus suudab VPN-kliendid üldse eristada. Kui iga klient saabub sama proksiaadressi kaudu, ei suuda allikapõhine lubamine neid eraldada ja nõue tuleb viia autentimisse või kliendipoolsele küljele.

Serveripoolne lubamine: keelduge allikast, mitte rakendusest

Hosti või võrgu tulemüür saab piirata meilikuulaja kinnitatud lähtevahemikega, jättes autentimise ja TLS-i muutmata. Reegli tingimus, mis vastab kaugtelefonidele, alamvõrkudele või vahemikele, on tavaline ehitusplokk; täpne süntaks kuulub serveri tulemüüritootele, mitte meilirakendusele.

See on tugevaim piir, kui nõue on „teenus ei tohi otsekliente teenindada“. See peab ka siis, kui kasutaja paigaldab teise meiliklendi, sest keeldumine toimub enne autentimist. See elab üle ka Maci, mis eirab oma VPN-poliitikat.

Selle piirang on sama oluline. Tagasi lükatud ühendus tõestab, et teenus keeldus seansist; see ei tõesta, et Mac ei teinud katset. DNS-i resolvimine, TCP SYN varasemale koormustasakaalustajale ja uus katse pärast ebaõnnestumist võivad kõik toimuda enne, kui serveri reeglini jõutakse. Kui nõue puudutab katsete avalikustamist, mitte juurdepääsu, on serveripoolne lubamine ainult pool kontrolli.

Kliendipoolne jõustamine: blokeerige katse, mitte ainult tunnel

Kliendipoolne reegel peab liikluse keelama, mitte ainult tunnelit käivitama, kui post avatakse. Meilidomeeni aktiveerimistriger võib VPN-i õigel hetkel üles tõsta, kuid see ei määratle, mis juhtub, kui tunnel on maas või pärast selle ebaõnnestumist.

Kasutage lõpp-punkti toote toetatud blokeerimispoliitikat ja määrake selle ulatus teadlikult. Rakenduse tasandi reegel katab kõik konto selles meilirakenduses, sealhulgas isiklikud. Sihtkoha tasandi reegel peab nimetama töökonto IMAP-, saatmis- ja autentimislõpp-punktid ning peab töötama ka siis, kui need aadressid muutuvad.

Katke mõlemad aadressiperekonnad ja olemasolevad seansid. Poliitika, mis blokeerib uued IPv4-ühendused, kuid jätab IPv6 või loodud pistiku puutumata, tekitab katkendlikku sünkroonimist, mis tundub juhuslik. Võrgu muutused ja unetsüklid on osa samast testist.

Rakenduse ja sihtkoha tasandi reeglitel on erinev mõjuala

Rakenduse tasandi blokeeringut on lihtne mõista: ükski liiklus ei lahku Postist ilma tunnelita. See on ka jäme, sest samas rakenduses võib olla isiklik konto, millel pole poliitikaga midagi pistmist. Kasutajad märkavad seda esimesena ja teatavad sellest kui katkisest meilirakendusest.

Sihtkoha tasandi blokeering on kitsam ja raskemini hooldatav. See vajab kogu lõpp-punktide komplekti, mida konto kasutab, sealhulgas avastamis- ja autentimisteenused, ning protsessi nende uuendamiseks. Üks jääb vahele ja konto töötab pooleldi; lisa liiga palju ja seostamatu post seiskub.

Valige nõude sõnastuse järgi. „See töökonto ei tohi otse ühenduda“ osutab sihtkoha ulatusele. „See Mac ei tohi posti väljaspool VPN-i ajada“ õigustab laiemat rakendusereeglit, kui omanik nõustub isikliku konto kõrvalmõjuga.

Testige keeldumist ja puudumist eraldi

Spetsiaalse testkontoga ühenduge VPN-i kaudu ja kinnitage normaalne töö. Seejärel katkestage ja testige kaks korda: korra, et näha, kas server keeldub sisselogimisest, ja korra, et näha, kas Mac üldse ühendust proovib. Need on erinevad vaatlused ja need kuuluvad erinevatesse logidesse.

Jälgige kliendipoolseid tõendeid SYN-i või DNS-päringu kohta, kui olete lahti ühendatud, ja serveripoolset logi tagasilükatud või vastuvõetud seansi kohta. Kui server keeldub, kuid klient ikka proovib, töötab serverireegel ja kliendireegel puudub. Kui klient ei proovi, kuid server võtab endiselt vastu teisi kliente, on piir täpselt seal, kuhu selle panite.

Märkige jõustamise omanik, lähteaadress, mida server tegelikult näeb, ja kasutatud testkonto. Järgmine võrgu- või proksimuudatus võib selle allika liigutada, ja vaadeldud väärtust nimetav märkus on kiirem kontrollida kui veel üks oletuste ring.