O e-mail chega ao servidor sem VPN: onde aplicar a regra

O e-mail continua consultando e a VPN está desligada, mas a conta ainda sincroniza. O aplicativo faz o que foi configurado para fazer; nada em um perfil de e-mail normal diz que o servidor só é acessível pelo túnel. Isso deixa dois requisitos diferentes, e é fácil confundi-los: o serviço deve recusar clientes diretos, ou o Mac nunca deve tentar.

Escolha o requisito antes de escolher um produto. Uma regra de servidor e uma regra de cliente falham em lugares diferentes, produzem evidências diferentes e pertencem a donos diferentes. Aplicar as duas é válido quando as duas afirmações são verdadeiras, mas uma não substitui a outra. Os dois requisitos são legítimos; simplesmente não são o mesmo controle.

O sintoma parece o Mac, mas o servidor pode ser o vazamento

Quando o e-mail sincroniza fora do túnel, comece pelo que o servidor aceita. Se o ouvinte de e-mail responde a uma conexão direta da internet, nenhum ajuste de conveniência do lado do cliente muda esse fato. O Mac se comporta normalmente diante de um serviço que ainda está aberto.

Pergunte ao administrador de e-mail qual endereço de origem o serviço vê. Um gateway VPN, proxy reverso ou balanceador de carga pode traduzir o endereço do cliente, então o pool de endereços na configuração da VPN pode não corresponder ao que chega ao processo de e-mail. Uma regra escrita contra a origem errada ou bloqueia todos ou não bloqueia ninguém.

Essa resposta também diz se o serviço consegue distinguir clientes VPN. Se cada cliente chega pelo mesmo endereço de proxy, a admissão baseada na origem não consegue separá-los, e o requisito precisa migrar para a autenticação ou para o lado do cliente.

Admissão no servidor: recuse a origem, não o aplicativo

Um firewall de host ou de rede pode restringir o ouvinte de e-mail a faixas de origem aprovadas enquanto deixa a autenticação e o TLS inalterados. Uma condição de regra que corresponde a endereços remotos, sub-redes ou faixas é o bloco de construção habitual; a sintaxe exata pertence ao produto de firewall do servidor, não ao aplicativo de e-mail.

Essa é a fronteira mais forte quando o requisito é «o serviço não deve atender clientes diretos». Ela resiste mesmo se o usuário instalar outro cliente de e-mail, porque a recusa acontece antes da autenticação. Também sobrevive a um Mac que ignora sua política de VPN.

O limite dela é igualmente importante. Uma conexão recusada prova que o serviço recusou a sessão; não prova que o Mac não tentou. Resolução de DNS, um TCP SYN para um balanceador de carga anterior e uma nova tentativa após falha podem todos acontecer antes de a regra do servidor ser alcançada. Se o requisito trata da divulgação de tentativas e não do acesso, a admissão no servidor é apenas metade do controle.

Aplicação no cliente: bloqueie a tentativa, não apenas o túnel

Uma regra do lado do cliente tem de proibir o tráfego, não apenas iniciar um túnel quando o e-mail é aberto. Um gatilho de ativação para um domínio de e-mail pode erguer a VPN no momento certo, mas não define o que acontece enquanto o túnel está desligado ou depois que falha.

Use a política de bloqueio compatível do produto de endpoint e delimite seu alcance de propósito. Uma regra em nível de aplicativo cobre cada conta daquele aplicativo de e-mail, incluindo as pessoais. Uma regra em nível de destino precisa nomear os endpoints IMAP, de envio e de autenticação da conta de trabalho, e precisa continuar funcionando quando esses endereços mudarem.

Cubra as duas famílias de endereços e as sessões existentes. Uma política que bloqueia conexões IPv4 novas enquanto deixa IPv6 ou um socket estabelecido em paz produz sincronizações intermitentes que parecem aleatórias. Mudanças de rede e ciclos de sono fazem parte do mesmo teste.

As regras em nível de aplicativo e de destino têm alcances diferentes

Um bloqueio em nível de aplicativo é simples de raciocinar: nenhum tráfego do Correio sai sem o túnel. Também é grosseiro, porque o mesmo aplicativo pode conter uma conta pessoal que nada tem a ver com a política. Os usuários percebem isso primeiro e relatam como um aplicativo de e-mail quebrado.

Um bloqueio em nível de destino é mais estreito e mais difícil de manter. Precisa do conjunto completo de endpoints que a conta usa, incluindo serviços de descoberta e autenticação, e de um processo para atualizá-los. Se faltar um, a conta funciona pela metade; se incluir demais, o e-mail não relacionado para.

Escolha conforme a redação do requisito. «Esta conta de trabalho não deve conectar diretamente» aponta para o escopo de destino. «Este Mac não deve rodar e-mail fora da VPN» justifica a regra de aplicativo mais ampla, desde que o dono aceite o efeito colateral na conta pessoal.

Teste a recusa e a ausência separadamente

Com uma conta de teste dedicada, conecte-se pela VPN e confirme o funcionamento normal. Depois desconecte e teste duas vezes: uma para ver se o servidor recusa o login, e outra para ver se o Mac tenta alguma conexão. São observações diferentes e pertencem a registros diferentes.

Observe as evidências do lado do cliente para um SYN ou uma consulta DNS enquanto está desconectado, e o log do servidor para uma sessão recusada ou aceita. Se o servidor recusa mas o cliente ainda tenta, a regra do servidor funciona e a do cliente falta. Se o cliente não tenta nada mas o servidor continua aceitando outros clientes, a fronteira está exatamente onde você a colocou.

Anote o responsável pela aplicação, o endereço de origem que o servidor realmente vê e a conta de teste usada. A próxima mudança de rede ou de proxy pode mover essa origem, e uma nota que nomeie o valor observado é mais rápida de verificar do que outra rodada de suposições.