El correo llega al servidor sin VPN: dónde aplicar la regla

El correo sigue consultando y la VPN está caída, pero la cuenta sigue sincronizándose. La aplicación hace lo que se configuró para hacer; nada en un perfil de correo normal dice que el servidor solo sea accesible por el túnel. Eso deja dos requisitos distintos, y es fácil confundirlos: el servicio debería rechazar a los clientes directos, o el Mac no debería hacer nunca el intento.

Elija el requisito antes de elegir un producto. Una regla de servidor y una regla de cliente fallan en lugares distintos, producen pruebas distintas y pertenecen a propietarios distintos. Aplicar ambas es válido cuando ambas afirmaciones son ciertas, pero una no sustituye a la otra. Ambos requisitos son legítimos; simplemente no son el mismo control.

El síntoma parece el Mac, pero el servidor puede ser la fuga

Cuando el correo se sincroniza fuera del túnel, empiece por lo que acepta el servidor. Si el escucha de correo responde a una conexión directa desde internet, ningún ajuste de comodidad del lado del cliente cambia ese hecho. El Mac se comporta con normalidad frente a un servicio que sigue abierto.

Pregunte al administrador de correo qué dirección de origen ve el servicio. Una puerta de enlace VPN, un proxy inverso o un balanceador de carga pueden traducir la dirección del cliente, así que el conjunto de direcciones de la configuración de VPN puede no coincidir con lo que llega al proceso de correo. Una regla escrita contra el origen equivocado o bloquea a todos o no bloquea a nadie.

Esa respuesta también dice si el servicio puede distinguir a los clientes VPN. Si cada cliente llega por la misma dirección de proxy, la admisión basada en el origen no puede separarlos, y el requisito tiene que trasladarse a la autenticación o al lado del cliente.

Admisión en el servidor: rechace el origen, no la aplicación

Un cortafuegos de host o de red puede restringir el escucha de correo a rangos de origen aprobados mientras deja la autenticación y TLS sin cambios. Una condición de regla que coincida con direcciones remotas, subredes o rangos es el bloque de construcción habitual; la sintaxis exacta pertenece al producto de cortafuegos del servidor, no a la aplicación de correo.

Esa es la frontera más fuerte cuando el requisito es «el servicio no debe atender a clientes directos». Aguanta incluso si el usuario instala otro cliente de correo, porque el rechazo ocurre antes de la autenticación. También sobrevive a un Mac que ignora su política de VPN.

Su límite es igual de importante. Una conexión rechazada demuestra que el servicio rechazó la sesión; no demuestra que el Mac no hiciera ningún intento. La resolución DNS, un TCP SYN hacia un balanceador de carga anterior y un reintento tras el fallo pueden ocurrir todos antes de que se alcance la regla del servidor. Si el requisito trata de la divulgación de intentos y no del acceso, la admisión en el servidor es solo la mitad del control.

Aplicación en el cliente: bloquee el intento, no solo el túnel

Una regla del lado del cliente tiene que prohibir el tráfico, no solo iniciar un túnel al abrir el correo. Un disparador de activación para un dominio de correo puede levantar la VPN en el momento adecuado, pero no define qué pasa mientras el túnel está caído o después de que falle.

Use la política de bloqueo compatible del producto de punto final y delimite su alcance a propósito. Una regla a nivel de aplicación cubre cada cuenta de esa aplicación de correo, incluidas las personales. Una regla a nivel de destino tiene que nombrar los puntos finales IMAP, de envío y de autenticación de la cuenta de trabajo, y tiene que seguir funcionando cuando esas direcciones cambien.

Cubra ambas familias de direcciones y las sesiones existentes. Una política que bloquea conexiones IPv4 nuevas mientras deja intactas IPv6 o un socket establecido produce sincronizaciones intermitentes que parecen aleatorias. Los cambios de red y los ciclos de sueño forman parte de la misma prueba.

Las reglas a nivel de aplicación y de destino tienen distinto alcance

Un bloqueo a nivel de aplicación es sencillo de razonar: ningún tráfico del Correo sale sin el túnel. También es contundente, porque la misma aplicación puede alojar una cuenta personal que no tiene nada que ver con la política. Los usuarios lo notan primero y lo reportan como una aplicación de correo rota.

Un bloqueo a nivel de destino es más estrecho y más difícil de mantener. Necesita el conjunto completo de puntos finales que usa la cuenta, incluidos los servicios de descubrimiento y autenticación, y un proceso para actualizarlos. Si falta uno, la cuenta funciona a medias; si incluye demasiados, el correo no relacionado se detiene.

Elija según la redacción del requisito. «Esta cuenta de trabajo no debe conectarse directamente» apunta al alcance de destino. «Este Mac no debe ejecutar correo fuera de la VPN» justifica la regla de aplicación más amplia, siempre que el propietario acepte el efecto secundario en la cuenta personal.

Pruebe el rechazo y la ausencia por separado

Con una cuenta de prueba dedicada, conéctese por la VPN y confirme el funcionamiento normal. Después desconecte y pruebe dos veces: una para ver si el servidor rechaza el inicio de sesión y otra para ver si el Mac intenta alguna conexión. Son observaciones distintas y pertenecen a registros distintos.

Observe las pruebas del lado del cliente en busca de un SYN o una consulta DNS mientras está desconectado, y el registro del servidor en busca de una sesión rechazada o aceptada. Si el servidor rechaza pero el cliente sigue intentándolo, la regla del servidor funciona y falta la del cliente. Si el cliente no hace ningún intento pero el servidor sigue aceptando a otros clientes, la frontera está exactamente donde usted la puso.

Anote el propietario de la aplicación, la dirección de origen que el servidor ve realmente y la cuenta de prueba utilizada. El siguiente cambio de red o de proxy puede mover ese origen, y una nota que nombre el valor observado se comprueba más rápido que otra ronda de conjeturas.