O correo chega ao servidor sen VPN: onde aplicar a regra

O correo segue consultando e a VPN está caída, pero a conta segue sincronizándose. A aplicación fai o que se configurou para facer; nada nun perfil de correo normal di que o servidor só sexa accesible polo túnel. Iso deixa dous requisitos distintos, e é fácil confundilos: o servizo debería rexeitar os clientes directos, ou o Mac non debería facer nunca o intento.

Escolla o requisito antes de escoller un produto. Unha regra de servidor e unha regra de cliente fallan en lugares distintos, producen probas distintas e pertencen a propietarios distintos. Aplicar ambas é válido cando ambas as afirmacións son certas, pero unha non substitúe a outra. Ambos os requisitos son lexítimos; simplemente non son o mesmo control.

O síntoma parece o Mac, pero o servidor pode ser a fuga

Cando o correo se sincroniza fóra do túnel, comece polo que acepta o servidor. Se o escoitador de correo responde a unha conexión directa desde internet, ningún axuste de comodidade do lado do cliente cambia ese feito. O Mac compórtase con normalidade fronte a un servizo que segue aberto.

Pregunte ao administrador de correo que enderezo de orixe ve o servizo. Unha pasarela VPN, un proxy inverso ou un balanceador de carga poden traducir o enderezo do cliente, así que o conxunto de enderezos da configuración da VPN pode non coincidir co que chega ao proceso de correo. Unha regra escrita contra a orixe equivocada ou bloquea a todos ou non bloquea a ninguén.

Esa resposta tamén di se o servizo pode distinguir os clientes VPN. Se cada cliente chega polo mesmo enderezo de proxy, a admisión baseada na orixe non os pode separar, e o requisito ten que trasladarse á autenticación ou ao lado do cliente.

Admisión no servidor: rexeite a orixe, non a aplicación

Unha devasa de host ou de rede pode restrinxir o escoitador de correo a rangos de orixe aprobados mentres deixa a autenticación e TLS sen cambios. Unha condición de regra que coincide con enderezos remotos, subredes ou rangos é o bloque de construción habitual; a sintaxe exacta pertence ao produto de devasa do servidor, non á aplicación de correo.

Esa é a fronteira máis forte cando o requisito é «o servizo non debe atender clientes directos». Aguanta mesmo se o usuario instala outro cliente de correo, porque o rexeitamento ocorre antes da autenticación. Tamén sobrevive a un Mac que ignora a súa política de VPN.

O seu límite é igual de importante. Unha conexión rexeitada demostra que o servizo rexeitou a sesión; non demostra que o Mac non fixese ningún intento. A resolución DNS, un TCP SYN cara a un balanceador de carga anterior e un novo intento tras o fallo poden ocorrer todos antes de que se acade a regra do servidor. Se o requisito trata da divulgación de intentos e non do acceso, a admisión no servidor é só a metade do control.

Aplicación no cliente: bloquee o intento, non só o túnel

Unha regra do lado do cliente ten que prohibir o tráfico, non só iniciar un túnel ao abrir o correo. Un disparador de activación para un dominio de correo pode levantar a VPN no momento axeitado, pero non define que pasa mentres o túnel está caído ou despois de que falle.

Use a política de bloqueo compatible do produto de punto final e delimite o seu alcance a propósito. Unha regra a nivel de aplicación cobre cada conta desa aplicación de correo, incluídas as persoais. Unha regra a nivel de destino ten que nomear os puntos finais IMAP, de envío e de autenticación da conta de traballo, e ten que seguir funcionando cando eses enderezos cambien.

Cubra ambas as familias de enderezos e as sesións existentes. Unha política que bloquea conexións IPv4 novas mentres deixa intactas IPv6 ou un socket establecido produce sincronizacións intermitentes que parecen aleatorias. Os cambios de rede e os ciclos de sono forman parte da mesma proba.

As regras a nivel de aplicación e de destino teñen distinto alcance

Un bloqueo a nivel de aplicación é sinxelo de razoar: ningún tráfico do Correo sae sen o túnel. Tamén é contundente, porque a mesma aplicación pode albergar unha conta persoal que non ten nada que ver coa política. Os usuarios nótao primeiro e repórtao como unha aplicación de correo rota.

Un bloqueo a nivel de destino é máis estreito e máis difícil de manter. Necesita o conxunto completo de puntos finais que usa a conta, incluídos os servizos de descuberta e autenticación, e un proceso para actualizalos. Se falta un, a conta funciona a medias; se inclúe demasiados, o correo non relacionado detense.

Escolla segundo a redacción do requisito. «Esta conta de traballo non debe conectarse directamente» apunta ao alcance de destino. «Este Mac non debe executar correo fóra da VPN» xustifica a regra de aplicación máis ampla, sempre que o propietario acepte o efecto secundario na conta persoal.

Probe o rexeitamento e a ausencia por separado

Cunha conta de proba dedicada, conéctese pola VPN e confirme o funcionamento normal. Despois desconecte e probe dúas veces: unha para ver se o servidor rexeita o inicio de sesión e outra para ver se o Mac tenta algunha conexión. Son observacións distintas e pertencen a rexistros distintos.

Observe as probas do lado do cliente en busca dun SYN ou unha consulta DNS mentres está desconectado, e o rexistro do servidor en busca dunha sesión rexeitada ou aceptada. Se o servidor rexeita pero o cliente segue intentándoo, a regra do servidor funciona e falta a do cliente. Se o cliente non fai ningún intento pero o servidor segue aceptando outros clientes, a fronteira está exactamente onde a puxo.

Anote o propietario da aplicación, o enderezo de orixe que o servidor ve realmente e a conta de proba utilizada. O seguinte cambio de rede ou de proxy pode mover esa orixe, e unha nota que nomee o valor observado compróbase máis rápido que outra rolda de conxecturas.