La posta raggiunge il server senza VPN: dove applicare la regola

La posta continua a interrogare e la VPN è abbassata, ma l’account si sincronizza ancora. L’app fa ciò per cui è stata configurata; nulla in un normale profilo di posta dice che il server sia raggiungibile solo tramite il tunnel. Questo lascia due requisiti diversi, ed è facile confonderli: il servizio deve rifiutare i client diretti, oppure il Mac non deve mai tentare.

Scegliete il requisito prima di scegliere un prodotto. Una regola lato server e una lato client falliscono in punti diversi, producono prove diverse e appartengono a proprietari diversi. Applicarle entrambe è valido quando entrambe le affermazioni sono vere, ma una non sostituisce l’altra. Entrambi i requisiti sono legittimi; semplicemente non sono lo stesso controllo.

Il sintomo sembra il Mac, ma il server può essere la fuga

Quando la posta si sincronizza fuori dal tunnel, partite da ciò che il server accetta. Se il listener di posta risponde a una connessione diretta da Internet, nessuna impostazione di comodità lato client cambia quel fatto. Il Mac si comporta normalmente verso un servizio ancora aperto.

Chiedete all’amministratore della posta quale indirizzo di origine vede il servizio. Un gateway VPN, un proxy inverso o un bilanciatore di carico possono tradurre l’indirizzo del client, quindi il pool di indirizzi nella configurazione VPN può non corrispondere a ciò che arriva al processo di posta. Una regola scritta contro l’origine sbagliata blocca tutti o nessuno.

Quella risposta dice anche se il servizio riesce a distinguere i client VPN. Se ogni client arriva tramite lo stesso indirizzo proxy, l’ammissione basata sull’origine non può separarli, e il requisito deve spostarsi sull’autenticazione o sul lato client.

Ammissione lato server: rifiutate l’origine, non l’applicazione

Un firewall dell’host o della rete può limitare il listener di posta a intervalli di origine approvati lasciando invariati autenticazione e TLS. Una condizione di regola che corrisponde a indirizzi remoti, sottoreti o intervalli è il normale blocco costitutivo; la sintassi esatta appartiene al prodotto firewall del server, non all’applicazione di posta.

È il confine più solido quando il requisito è «il servizio non deve servire i client diretti». Tiene anche se l’utente installa un altro client di posta, perché il rifiuto avviene prima dell’autenticazione. Sopravvive anche a un Mac che ignora la sua politica VPN.

Il suo limite è altrettanto importante. Una connessione rifiutata dimostra che il servizio ha rifiutato la sessione; non dimostra che il Mac non abbia tentato. La risoluzione DNS, un TCP SYN verso un bilanciatore di carico precedente e un nuovo tentativo dopo un errore possono tutti avvenire prima che la regola del server venga raggiunta. Se il requisito riguarda la divulgazione dei tentativi e non l’accesso, l’ammissione lato server è solo metà del controllo.

Applicazione lato client: bloccate il tentativo, non solo il tunnel

Una regola lato client deve vietare il traffico, non solo avviare un tunnel all’apertura della posta. Un attivatore per un dominio di posta può alzare la VPN al momento giusto, ma non definisce cosa succede mentre il tunnel è abbassato o dopo che fallisce.

Usate la politica di blocco supportata dal prodotto endpoint e delimitatene la portata deliberatamente. Una regola a livello di applicazione copre ogni account di quell’app di posta, compresi quelli personali. Una regola a livello di destinazione deve nominare gli endpoint IMAP, di invio e di autenticazione dell’account di lavoro, e deve continuare a funzionare quando quegli indirizzi cambiano.

Coprite entrambe le famiglie di indirizzi e le sessioni esistenti. Una politica che blocca le nuove connessioni IPv4 lasciando in pace IPv6 o un socket stabilito produce sincronizzazioni intermittenti che sembrano casuali. I cambi di rete e i cicli di sonno fanno parte della stessa prova.

Le regole a livello di applicazione e di destinazione hanno una portata diversa

Un blocco a livello di applicazione è semplice da ragionare: nessun traffico dalla Posta esce senza il tunnel. È anche brutale, perché la stessa applicazione può contenere un account personale che non ha nulla a che fare con la politica. Gli utenti lo notano per primi e lo segnalano come app di posta rotta.

Un blocco a livello di destinazione è più stretto e più difficile da mantenere. Richiede l’insieme completo degli endpoint usati dall’account, compresi i servizi di individuazione e autenticazione, e un processo per aggiornarli. Se ne manca uno l’account funziona a metà; se ne includete troppi, la posta non correlata si ferma.

Scegliete in base alla formulazione del requisito. «Questo account di lavoro non deve connettersi direttamente» punta alla portata di destinazione. «Questo Mac non deve far girare la posta fuori dalla VPN» giustifica la regola di applicazione più ampia, purché il proprietario accetti l’effetto collaterale sull’account personale.

Provate il rifiuto e l’assenza separatamente

Con un account di prova dedicato, connettetevi tramite la VPN e confermate il funzionamento normale. Poi disconnettetevi e provate due volte: una per vedere se il server rifiuta l’accesso, e una per vedere se il Mac tenta qualche connessione. Sono osservazioni diverse e appartengono a registri diversi.

Osservate le prove lato client per un SYN o una query DNS mentre siete disconnessi, e il registro del server per una sessione rifiutata o accettata. Se il server rifiuta ma il client tenta ancora, la regola del server funziona e quella del client manca. Se il client non tenta nulla ma il server accetta ancora altri client, il confine è esattamente dove l’avete messo.

Annotate il proprietario dell’applicazione, l’indirizzo di origine che il server vede davvero e l’account di prova usato. Il prossimo cambio di rete o di proxy può spostare quell’origine, e una nota che nomina il valore osservato si verifica più in fretta di un altro giro di congetture.