Posta arrin serverin pa VPN: ku duhet zbatuar rregulli

Posta vazhdon të pyesë dhe VPN është i fikur, por llogaria ende sinkronizohet. Aplikacioni bën atë për të cilën është konfiguruar; asgjë në një profil normal poste nuk thotë se serveri arrihet vetëm përmes tunelit. Kjo lë dy kërkesa të ndryshme, dhe është e lehtë t’i ngatërrosh: shërbimi duhet të refuzojë klientët e drejtpërdrejtë, ose Mac nuk duhet ta provojë fare.

Zgjidhni kërkesën përpara se të zgjidhni një produkt. Një rregull serveri dhe një rregull klienti dështojnë në vende të ndryshme, prodhojnë prova të ndryshme dhe u përkasin pronarëve të ndryshëm. Zbatimi i të dyjave është i vlefshëm kur të dyja deklaratat janë të vërteta, por njëra nuk e zëvendëson tjetrën. Të dyja kërkesat janë legjitime; thjesht nuk janë i njëjti kontroll.

Simptoma duket si Mac, por rrjedhja mund të jetë në server

Kur posta sinkronizohet jashtë tunelit, filloni me atë që serveri pranon. Nëse dëgjuesi i postës përgjigjet një lidhjeje të drejtpërdrejtë nga interneti, asnjë cilësim komoditeti në anën e klientit nuk e ndryshon këtë fakt. Mac sillet normalisht ndaj një shërbimi që është ende i hapur.

Pyetni administratorin e postës se cilën adresë burimore sheh shërbimi. Një portë VPN, një proxy i kundërt ose një balancues ngarkese mund të përkthejnë adresën e klientit, kështu që grupi i adresave në konfigurimin e VPN mund të mos përputhet me atë që arrin në procesin e postës. Një rregull i shkruar kundër burimit të gabuar ose bllokon të gjithë ose nuk bllokon askënd.

Ai përgjigje tregon gjithashtu nëse shërbimi mund t’i dallojë fare klientët VPN. Nëse çdo klient vjen përmes të njëjtës adresë proxy, pranimi i bazuar në burim nuk mund t’i ndajë ata, dhe kërkesa duhet të kalojë te autentifikimi ose te ana e klientit.

Pranimi në server: refuzoni burimin, jo aplikacionin

Një firewall hosti ose rrjeti mund ta kufizojë dëgjuesin e postës në intervale burimore të miratuara, duke lënë autentifikimin dhe TLS të pandryshuar. Një kusht rregulli që përputhet me adresa të largëta, nënrrjeta ose intervale është blloku i zakonshëm i ndërtimit; sintaksa e saktë i përket produktit të firewall-it të serverit, jo aplikacionit të postës.

Ky është kufiri më i fortë kur kërkesa është «shërbimi nuk duhet t’u shërbejë klientëve të drejtpërdrejtë». Qëndron edhe nëse përdoruesi instalon një klient tjetër poste, sepse refuzimi ndodh përpara autentifikimit. I reziston edhe një Mac që injoron politikën e tij të VPN.

Kufiri i tij është po aq i rëndësishëm. Një lidhje e refuzuar provon se shërbimi e refuzoi sesionin; nuk provon se Mac nuk bëri asnjë përpjekje. Zgjidhja DNS, një TCP SYN drejt një balancuesi ngarkese të mëparshëm dhe një ripërpjekje pas dështimit mund të ndodhin të gjitha përpara se të arrihet rregulli i serverit. Nëse kërkesa ka të bëjë me zbulimin e përpjekjeve dhe jo me aksesin, pranimi në server është vetëm gjysma e kontrollit.

Zbatimi në klient: bllokoni përpjekjen, jo vetëm tunelin

Një rregull në anën e klientit duhet të ndalojë trafikun, jo thjesht të nisë një tunel kur hapet posta. Një shkas aktivizimi për një domen poste mund ta ngrejë VPN-në në momentin e duhur, por nuk përcakton çfarë ndodh ndërsa tuneli është i fikur ose pasi dështon.

Përdorni politikën e bllokimit të mbështetur nga produkti i pikës fundore dhe përcaktoni qëllimisht shtrirjen e saj. Një rregull në nivel aplikacioni mbulon çdo llogari në atë aplikacion poste, përfshirë ato personale. Një rregull në nivel destinacioni duhet të përmendë pikat fundore IMAP, të dërgimit dhe të autentifikimit të llogarisë së punës, dhe duhet të vazhdojë të funksionojë kur ato adresa ndryshojnë.

Mbuloni të dy familjet e adresave dhe sesionet ekzistuese. Një politikë që bllokon lidhjet e reja IPv4 por lë në paqe IPv6 ose një socket të vendosur prodhon sinkronizime të ndërprera që duken të rastësishme. Ndryshimet e rrjetit dhe ciklet e gjumit janë pjesë e të njëjtit test.

Rregullat në nivel aplikacioni dhe destinacioni kanë shtrirje të ndryshme

Një bllokim në nivel aplikacioni është i thjeshtë për t’u menduar: asnjë trafik nga Posta nuk del pa tunelin. Është gjithashtu i përgjithshëm, sepse i njëjti aplikacion mund të mbajë një llogari personale që nuk ka lidhje me politikën. Përdoruesit e vënë re këtë të parët dhe e raportojnë si aplikacion poste të prishur.

Një bllokim në nivel destinacioni është më i ngushtë dhe më i vështirë për t’u mirëmbajtur. Kërkon grupin e plotë të pikave fundore që përdor llogaria, përfshirë shërbimet e zbulimit dhe autentifikimit, dhe një proces për përditësimin e tyre. Mungon njëra dhe llogaria punon gjysmë; përfshini shumë dhe posta e palidhur ndalon.

Zgjidhni sipas formulimit të kërkesës. «Kjo llogari pune nuk duhet të lidhet drejtpërdrejt» tregon shtrirjen e destinacionit. «Ky Mac nuk duhet të drejtojë postë jashtë VPN» justifikon rregullin më të gjerë të aplikacionit, me kusht që pronari të pranojë efektin anësor te llogaria personale.

Testoni refuzimin dhe mungesën veçmas

Me një llogari testuese të dedikuar, lidhuni përmes VPN dhe konfirmoni funksionimin normal. Pastaj shkëputuni dhe testoni dy herë: një herë për të parë nëse serveri e refuzon hyrjen, dhe një herë për të parë nëse Mac provon ndonjë lidhje. Këto janë vëzhgime të ndryshme dhe i përkasin regjistrave të ndryshëm.

Shikoni provat në anën e klientit për një SYN ose një pyetje DNS ndërsa jeni i shkëputur, dhe regjistrin e serverit për një sesion të refuzuar ose të pranuar. Nëse serveri refuzon por klienti ende provon, rregulli i serverit funksionon dhe rregulli i klientit mungon. Nëse klienti nuk provon por serveri ende pranon klientë të tjerë, kufiri është pikërisht aty ku e vendosët.

Shënoni pronarin e zbatimit, adresën burimore që serveri sheh vërtet dhe llogarinë testuese të përdorur. Ndryshimi i radhës i rrjetit ose proxy mund ta zhvendosë atë burim, dhe një shënim që emërton vlerën e vëzhguar verifikohet më shpejt sesa një raund tjetër hamendjesh.