A levél VPN nélkül is eléri a szervert: hol kell érvényesíteni a szabályt

A levél tovább kérdez, a VPN pedig leállt, de a fiók mégis szinkronizál. Az alkalmazás azt teszi, amire beállították; egy rendes levélprofilban semmi sem mondja, hogy a szerver csak az alagúton át érhető el. Ez két különböző követelményt hagy, és könnyű összekeverni őket: a szolgáltatás utasítsa el a közvetlen klienseket, vagy a Mac ne is próbálkozzon.

A követelményt a termék kiválasztása előtt válassza ki. A kiszolgálói szabály és az ügyfélszabály más helyen hibázik, más bizonyítékot ad, és más tulajdonoshoz tartozik. Mindkettő alkalmazása akkor érvényes, ha mindkét állítás igaz, de az egyik nem helyettesíti a másikat. Mindkét követelmény jogos; csak nem ugyanaz a kontroll.

A tünet a Macre hasonlít, de a szerver lehet a szivárgás

Amikor a levél az alagúton kívül szinkronizál, kezdje azzal, amit a szerver elfogad. Ha a levélfigyelő válaszol az internetről érkező közvetlen kapcsolatra, semmilyen ügyféloldali kényelmi beállítás nem változtat ezen a tényen. A Mac normálisan viselkedik egy még nyitott szolgáltatással szemben.

Kérdezze meg a levélrendszergazdát, melyik forrás címet látja a szolgáltatás. Egy VPN-átjáró, fordított proxy vagy terheléselosztó átfordíthatja az ügyfél címét, ezért a VPN-konfiguráció címtartománya nem feltétlenül egyezik azzal, ami a levélfolyamathoz érkezik. A rossz forrás ellen írt szabály vagy mindenkit blokkol, vagy senkit.

Ez a válasz azt is megmondja, egyáltalán meg tudja-e különböztetni a szolgáltatás a VPN-klienseket. Ha minden ügyfél ugyanazon a proxycímen érkezik, a forrásalapú beengedés nem tudja szétválasztani őket, és a követelménynek az azonosításra vagy az ügyféloldalra kell átkerülnie.

Szerveroldali beengedés: a forrást utasítsa el, ne az alkalmazást

Egy gazdagép- vagy hálózati tűzfal a levélfigyelőt jóváhagyott forrástartományokra korlátozhatja, miközben az azonosítás és a TLS változatlan marad. A távoli címekre, alhálózatokra vagy tartományokra illeszkedő szabályfeltétel a szokásos építőelem; a pontos szintaxis a szerver tűzfaltermékéhez tartozik, nem a levelezőalkalmazáshoz.

Ez a legerősebb határ, amikor a követelmény az, hogy „a szolgáltatás nem szolgálhat ki közvetlen klienseket”. Akkor is tart, ha a felhasználó másik levélklienst telepít, mert az elutasítás az azonosítás előtt történik. Túléli azt a Macet is, amely figyelmen kívül hagyja a VPN-szabályzatát.

A korlátja ugyanolyan fontos. Az elutasított kapcsolat bizonyítja, hogy a szolgáltatás elutasította a munkamenetet; nem bizonyítja, hogy a Mac nem próbálkozott. A DNS-feloldás, egy TCP SYN egy korábbi terheléselosztóhoz és egy újrapróbálkozás hiba után mind megtörténhet, mielőtt a szerver szabályához érünk. Ha a követelmény a próbálkozások nyilvánosságra hozataláról szól, nem a hozzáférésről, akkor a szerveroldali beengedés csak a kontroll fele.

Kényszerítés az ügyfélen: a próbálkozást blokkolja, ne csak az alagutat

Az ügyféloldali szabálynak tiltania kell a forgalmat, nem csak alagutat indítania a levél megnyitásakor. Egy levél-domain aktiválási eseménye a megfelelő pillanatban felhozhatja a VPN-t, de nem határozza meg, mi történik, amíg az alagút áll, vagy miután meghiúsul.

Használja a végponttermék támogatott blokkolási szabályzatát, és szándékosan határolja be a hatókörét. Az alkalmazásszintű szabály lefedi az adott levelezőalkalmazás minden fiókját, a személyeseket is. A célszintű szabálynak meg kell neveznie a munkafiók IMAP-, küldési és azonosítási végpontjait, és működnie kell akkor is, amikor ezek a címek megváltoznak.

Fedje le mindkét címcsaládot és a meglévő munkameneteket. Az a szabályzat, amely blokkolja az új IPv4-kapcsolatokat, de az IPv6-ot vagy egy létrejött socketet érintetlenül hagy, időszakos szinkronizálásokat okoz, amelyek véletlenszerűnek tűnnek. A hálózati változások és az alvási ciklusok ugyanannak a tesztnek a részei.

Az alkalmazás- és célszintű szabályok hatóköre eltér

Az alkalmazásszintű blokk egyszerűen átgondolható: a Levélből semmi nem lép ki az alagút nélkül. Ez durva is, mert ugyanabban az alkalmazásban lehet olyan személyes fiók, amelynek semmi köze a szabályzathoz. A felhasználók ezt veszik észre először, és hibás levelezőalkalmazásként jelentik.

A célszintű blokk szűkebb és nehezebben tartható karban. Szüksége van a fiók által használt végpontok teljes halmazára, beleértve a felderítési és azonosítási szolgáltatásokat, valamint egy folyamatra ezek frissítéséhez. Egy hiányzik, és a fiók félgőzzel működik; túl sokat vesz bele, és a nem kapcsolódó levél megáll.

A követelmény megfogalmazása szerint válasszon. A „ez a munkafiók nem kapcsolódhat közvetlenül“ célszintű hatókörre mutat. A „ez a Mac nem futtathat levelet a VPN-en kívül“ igazolja a tágabb alkalmazásszabályt, feltéve hogy a tulajdonos elfogadja a személyes fiók mellékhatását.

Az elutasítást és a hiányt külön vizsgálja

Egy dedikált tesztfiókkal kapcsolódjon a VPN-en át, és erősítse meg a normál működést. Ezután szakítsa meg, és kétszer vizsgálja: egyszer, hogy a szerver elutasítja-e a bejelentkezést, egyszer pedig, hogy a Mac egyáltalán próbál-e kapcsolatot. Ezek különböző megfigyelések, és különböző naplókba tartoznak.

Figyelje az ügyféloldali bizonyítékokat egy SYN vagy DNS-kérés után, miközben le van választva, és a szervernaplót egy elutasított vagy elfogadott munkamenet után. Ha a szerver elutasít, de az ügyfél tovább próbálkozik, a szerverszabály működik, és az ügyfélszabály hiányzik. Ha az ügyfél nem próbálkozik, de a szerver továbbra is elfogad más ügyfeleket, a határ pontosan ott van, ahova tette.

Jegyezze fel az érvényesítés tulajdonosát, a forráscímet, amelyet a szerver valóban lát, és a használt tesztfiókot. A következő hálózati vagy proxyváltozás elmozdíthatja ezt a forrást, és a megfigyelt értéket megnevező feljegyzés gyorsabban ellenőrizhető, mint egy újabb találgatási kör.