Retpoŝto atingas la servilon sen VPN: kie apliki la regulon

Retpoŝto daŭre demandas kaj la VPN estas malsupra, tamen la konto ankoraŭ sinkroniĝas. La aplikaĵo faras tion, por kio ĝi estis agordita; nenio en normala retpoŝta profilo diras, ke la servilo atingeblas nur tra la tunelo. Tio lasas du malsamajn postulojn, kaj facile estas konfuzi ilin: la servo devus rifuzi rektajn klientojn, aŭ la Mac tute ne devus fari la provon.

Elektu la postulon antaŭ ol elekti produkton. Servila regulo kaj klienta regulo malsukcesas en malsamaj lokoj, produktas malsamajn pruvojn kaj apartenas al malsamaj posedantoj. Apliki ambaŭ estas valida, kiam ambaŭ asertoj veras, sed unu ne anstataŭas la alian. Ambaŭ postuloj estas legitimaj; ili simple ne estas la sama kontrolo.

La simptomo aspektas kiel la Mac, sed la servilo povas esti la liko

Kiam retpoŝto sinkroniĝas ekster la tunelo, komencu per tio, kion la servilo akceptas. Se la retpoŝta aŭskultanto respondas al rekta konekto el la interreto, neniu komforta agordo ĉe la klienta flanko ŝanĝas tiun fakton. La Mac kondutas normale rilate al servo, kiu ankoraŭ estas malfermita.

Demandu la retpoŝtan administranton, kiun fontan adreson la servo vidas. VPN-enirejo, inversa prokurilo aŭ ŝarĝa ekvilibrigilo povas traduki la klientan adreson, do la adresaro en la VPN-agordo eble ne kongruas kun tio, kio alvenas al la retpoŝta procezo. Regulo skribita kontraŭ la malĝusta fonto aŭ blokas ĉiujn aŭ blokas neniun.

Tiu respondo ankaŭ diras, ĉu la servo entute povas distingi VPN-klientojn. Se ĉiu kliento alvenas tra la sama prokura adreso, fontbazita akcepto ne povas apartigi ilin, kaj la postulo devas moviĝi al aŭtentigo aŭ al la klienta flanko.

Servila akcepto: rifuzu la fonton, ne la aplikaĵon

Gastiga aŭ reta fajroŝirmilo povas limigi la retpoŝtan aŭskultanton al aprobitaj fontaj intervaloj, lasante aŭtentigon kaj TLS senŝanĝaj. Regula kondiĉo, kiu kongruas forajn adresojn, subretojn aŭ intervalojn, estas la kutima konstrua bloko; la preciza sintakso apartenas al la fajroŝirmila produkto de la servilo, ne al la retpoŝta aplikaĵo.

Tio estas la plej forta limo, kiam la postulo estas «la servo ne devas servi rektajn klientojn». Ĝi teniĝas eĉ se la uzanto instalas alian retpoŝtan klienton, ĉar la rifuzo okazas antaŭ aŭtentigo. Ĝi ankaŭ postvivas Mac-on, kiu ignoras sian VPN-politikon.

Ĝia limo same gravas. Rifuzita konekto pruvas, ke la servo rifuzis la seancon; ĝi ne pruvas, ke la Mac faris neniun provon. DNS-eligo, TCP SYN al pli frua ŝarĝa ekvilibrigilo kaj rea provo post malsukceso povas ĉiuj okazi antaŭ ol oni atingas la servilan regulon. Se la postulo temas pri malkaŝo de provoj anstataŭ pri aliro, servila akcepto estas nur duono de la kontrolo.

Klienta devigo: bloku la provon, ne nur la tunnelon

Klientflanka regulo devas malpermesi la trafikon, ne simple startigi tunnelon kiam retpoŝto malfermiĝas. Aktiviga ellasilo por retpoŝta domajno povas levi la VPN je la ĝusta momento, sed ĝi ne difinas, kio okazas dum la tunelo estas malsupra aŭ post kiam ĝi malsukcesas.

Uzu la subtenatan blokan politikon de la finpunkta produkto kaj difinu ĝian amplekson konscie. Regulo je aplikaĵa nivelo kovras ĉiun konton en tiu retpoŝta aplikaĵo, inkluzive personajn. Regulo je celloka nivelo devas nomi la IMAP-, sendajn kaj aŭtentigajn finpunktojn de la labora konto, kaj ĝi devas daŭre funkcii kiam tiuj adresoj ŝanĝiĝas.

Kovru ambaŭ adresajn familiojn kaj ekzistantajn seancojn. Politiko, kiu blokas novajn IPv4-konektojn dum ĝi lasas IPv6 aŭ establitan ingon trankvila, produktas intermitajn sinkronigojn, kiuj aspektas hazardaj. Retaj ŝanĝoj kaj dormaj cikloj estas parto de la sama testo.

Reguloj je aplikaĵa kaj celloka niveloj havas malsaman efikradiuson

Blokado je aplikaĵa nivelo estas simple pripensebla: neniu trafiko el Retpoŝto eliras sen la tunelo. Ĝi ankaŭ estas maldelikata, ĉar la sama aplikaĵo povas teni personan konton, kiu havas nenion komunan kun la politiko. Uzantoj rimarkas tion unue kaj raportas ĝin kiel difektitan retpoŝtan aplikaĵon.

Blokado je celloka nivelo estas pli mallarĝa kaj pli malfacile prizorgata. Ĝi bezonas la kompletan aron da finpunktoj, kiujn la konto uzas, inkluzive malkovrajn kaj aŭtentigajn servojn, kaj procezon por ĝisdatigi ilin. Maltrafu unu kaj la konto duone funkcias; inkluzivu tro multe kaj nerilata retpoŝto haltas.

Elektu laŭ la vortumo de la postulo. «Ĉi tiu labora konto ne devas konektiĝi rekte» montras al celloka amplekso. «Ĉi tiu Mac ne devas funkciigi retpoŝton ekster la VPN» pravigas la pli vastan aplikaĵan regulon, kondiĉe ke la posedanto akceptas la flankan efikon por la persona konto.

Testu rifuzon kaj foreston aparte

Kun dediĉita testa konto, konektiĝu tra la VPN kaj konfirmu normalan funkciadon. Poste malkonektiĝu kaj testu dufoje: unufoje por vidi, ĉu la servilo rifuzas la salutong, kaj unufoje por vidi, ĉu la Mac entute provas konekton. Tiuj estas malsamaj observoj kaj ili apartenas al malsamaj protokoloj.

Rigardu la klientflankajn pruvojn pri SYN aŭ DNS-demando dum vi estas malkonektita, kaj la servilan protokolon pri rifuzita aŭ akceptita seanco. Se la servilo rifuzas sed la kliento ankoraŭ provas, la servila regulo funkcias kaj la klienta regulo mankas. Se la kliento faras neniun provon sed la servilo ankoraŭ akceptas aliajn klientojn, la limo estas ĝuste tie, kie vi metis ĝin.

Notu la posedanton de la devigo, la fontan adreson, kiun la servilo efektive vidas, kaj la uzitan testan konton. La sekva reta aŭ prokura ŝanĝo povas movi tiun fonton, kaj noto nomanta la observitan valoron estas pli rapide kontrolebla ol plia raŭndo da divenado.