Pos bereik die bediener sonder VPN: waar om die reël toe te pas

Pos bly peil en die VPN is af, maar die rekening sinkroniseer steeds. Die program doen wat dit ingestel is om te doen; niks in ’n normale posprofiel sê die bediener is net deur die tonnel bereikbaar nie. Dit laat twee verskillende vereistes oor, en hulle is maklik om te verwar: die diens moet direkte kliënte weier, of die Mac moet nooit die poging maak nie.

Kies die vereiste voordat jy ’n produk kies. ’n Bedienerreël en ’n kliëntreël faal op verskillende plekke, lewer verskillende bewyse en behoort aan verskillende eienaars. Om albei toe te pas is geldig wanneer albei stellings waar is, maar een is nie ’n plaasvervanger vir die ander nie. Albei vereistes is wettig; hulle is net nie dieselfde beheer nie.

Die simptoom lyk soos die Mac, maar die bediener kan die lek wees

Wanneer pos buite die tonnel sinkroniseer, begin by wat die bediener aanvaar. As die posluisteraar ’n direkte verbinding van die internet beantwoord, verander geen kliëntkant-gemakinstelling daardie feit nie. Die Mac tree normaal op teenoor ’n diens wat steeds oop is.

Vra die posadministrateur watter bronadres die diens sien. ’n VPN-grendel, omgekeerde instaanbediener of lasbalanseerder kan die kliëntadres vertaal, so die adrespoel in die VPN-konfigurasie stem dalk nie ooreen met wat by die posproses aankom nie. ’n Reël wat teen die verkeerde bron geskryf is, blokkeer almal of blokkeer niemand.

Daardie antwoord sê ook vir jou of die diens VPN-kliënte hoegenaamd kan onderskei. As elke kliënt deur dieselfde instaanadres aankom, kan brongebaseerde toelating hulle nie skei nie, en die vereiste moet na verifikasie of na die kliëntkant skuif.

Bediener-toelating: weier die bron, nie die program nie

’n Gasheer- of netwerkbrandmuur kan die posluisteraar tot goedgekeurde bronreekse beperk terwyl verifikasie en TLS onveranderd bly. ’n Reëlvoorwaarde wat afgeleë adresse, subnetwerke of reekse pas, is die gewone boublok; die presiese sintaks hoort by die bediener se brandmuurproduk, nie by die posprogram nie.

Dit is die sterkste grens wanneer die vereiste is “die diens mag nie direkte kliënte bedien nie”. Dit hou selfs as die gebruiker ’n ander posprogram installeer, want die weiering gebeur voor verifikasie. Dit oorleef ook ’n Mac wat sy VPN-beleid ignoreer.

Die beperking daarvan is ewe belangrik. ’n Verwerpte verbinding bewys die diens het die sitting geweier; dit bewys nie die Mac het geen poging gemaak nie. DNS-resolusie, ’n TCP SYN na ’n vroeëre lasbalanseerder en ’n herprobeer ná mislukking kan alles gebeur voordat die bediener se reël bereik word. As die vereiste oor openbaarmaking van pogings gaan eerder as oor toegang, is bediener-toelating net die helfte van die beheer.

Kliënt-afdwinging: blokkeer die poging, nie net die tonnel nie

’n Kliëntkant-reël moet die verkeer verbied, nie bloot ’n tonnel begin wanneer pos oopgemaak word nie. ’n Aktiveringssneller vir ’n posdomein kan die VPN op die regte oomblik opbring, maar dit bepaal nie wat gebeur terwyl die tonnel af is of nadat dit misluk nie.

Gebruik die eindpuntproduk se ondersteunde blokkeringsbeleid en beperk die omvang daarvan doelbewus. ’n Reël op programvlak dek elke rekening in daardie posprogram, ook persoonlike rekeninge. ’n Reël op bestemmingsvlak moet die werkrekening se IMAP-, indienings- en verifikasiemodelpunte noem, en dit moet bly werk wanneer daardie adresse verander.

Dek albei adresfamilies en bestaande sittings. ’n Beleid wat nuwe IPv4-verbindings blokkeer terwyl IPv6 of ’n gevestigde sok ongemoeid gelaat word, produseer onderbroke sinchroniserings wat willekeurig lyk. Netwerkveranderings en slaapsiklusse is deel van dieselfde toets.

Reëls op programvlak en bestemmingsvlak het verskillende impak

’n Blokkade op programvlak is eenvoudig om te beredeneer: geen verkeer van Pos verlaat sonder die tonnel nie. Dit is ook grof, want dieselfde program kan ’n persoonlike rekening hou wat niks met die beleid te doen het nie. Gebruikers merk dit eerste op en rapporteer dit as ’n stukkende posprogram.

’n Blokkade op bestemmingsvlak is smaller en moeiliker om te onderhou. Dit benodig die volledige stel modelpunte wat die rekening gebruik, insluitend ontdekkings- en verifikasiemodelpunte, en ’n proses om hulle by te werk. Misluk een en die rekening werk half; sluit te veel in en onverwante pos stop.

Kies volgens die bewoording van die vereiste. “Hierdie werkrekening mag nie direk verbind nie” wys na bestemmingsomvang. “Hierdie Mac mag nie pos buite die VPN laat loop nie” regverdig die breër programreël, mits die eienaar die newe-effek op persoonlike rekeninge aanvaar.

Toets weiering en afwesigheid afsonderlik

Met ’n toegewyde toetsrekening, verbind deur die VPN en bevestig normale werking. Ontkoppel dan en toets twee keer: een keer om te sien of die bediener die aanmelding weier, en een keer om te sien of die Mac hoegenaamd ’n verbinding probeer. Dit is verskillende waarnemings en hulle hoort in verskillende logs.

Kyk na die kliëntkant-bewyse vir ’n SYN of ’n DNS-navraag terwyl jy ontkoppel is, en na die bedienerkant-log vir ’n verwerpte of aanvaarde sitting. As die bediener weier maar die kliënt probeer steeds, werk die bedienerreël en ontbreek die kliëntreël. As die kliënt geen poging maak nie maar die bediener aanvaar steeds ander kliënte, is die grens presies waar jy dit geplaas het.

Teken die afdwingingseienaar aan, die bronadres wat die bediener werklik sien, en die toetsrekening wat gebruik is. Die volgende netwerk- of instaanverandering kan daardie bron verskuif, en ’n nota wat die waargenome waarde noem, is vinniger om te kontroleer as nog ’n ronde raaiwerk.