El correu arriba al servidor sense VPN: on aplicar la regla

El correu continua fent consultes i la VPN està caiguda, però el compte encara se sincronitza. L’aplicació fa el que se li va configurar; res en un perfil de correu normal diu que el servidor només sigui abastable a través del túnel. Això deixa dos requisits diferents, i és fàcil confondre’ls: el servei hauria de rebutjar els clients directes, o el Mac no hauria de fer mai l’intent.

Trieu el requisit abans de triar un producte. Una regla de servidor i una regla de client fallen en llocs diferents, produeixen proves diferents i pertanyen a propietaris diferents. Aplicar-les totes dues és vàlid quan les dues afirmacions són certes, però una no substitueix l’altra. Els dos requisits són legítims; simplement no són el mateix control.

El símptoma sembla el Mac, però el servidor pot ser la fuita

Quan el correu se sincronitza fora del túnel, comenceu pel que accepta el servidor. Si l’oient de correu respon a una connexió directa d’Internet, cap paràmetre de comoditat del costat del client canvia aquest fet. El Mac es comporta amb normalitat davant d’un servei que encara és obert.

Pregunteu a l’administrador de correu quina adreça d’origen veu el servei. Una passarel·la VPN, un proxy invers o un balancejador de càrrega poden traduir l’adreça del client, de manera que el conjunt d’adreces de la configuració VPN pot no coincidir amb el que arriba al procés de correu. Una regla escrita contra l’origen equivocat o bloqueja tothom o no bloqueja ningú.

Aquesta resposta també us diu si el servei pot distingir els clients VPN. Si cada client arriba per la mateixa adreça de proxy, l’admissió basada en l’origen no els pot separar, i el requisit s’ha de traslladar a l’autenticació o al costat del client.

Admissió al servidor: rebutgeu l’origen, no l’aplicació

Un tallafoc d’amfitrió o de xarxa pot restringir l’oient de correu a rangs d’origen aprovats mentre deixa l’autenticació i el TLS sense canvis. Una condició de regla que coincideix amb adreces remotes, subxarxes o rangs és el bloc de construcció habitual; la sintaxi exacta pertany al producte de tallafoc del servidor, no a l’aplicació de correu.

Aquesta és la frontera més forta quan el requisit és «el servei no ha de servir clients directes». Aguanta fins i tot si l’usuari instal·la un altre client de correu, perquè el rebuig passa abans de l’autenticació. També sobreviu a un Mac que ignora la seva política de VPN.

El seu límit és igual d’important. Una connexió rebutjada demostra que el servei va refusar la sessió; no demostra que el Mac no fes cap intent. La resolució DNS, un TCP SYN cap a un balancejador de càrrega anterior i un reintent després del fracàs poden passar tots abans que s’assoleixi la regla del servidor. Si el requisit tracta de la divulgació d’intents i no de l’accés, l’admissió al servidor és només la meitat del control.

Aplicació al client: bloquegeu l’intent, no només el túnel

Una regla del costat del client ha de prohibir el trànsit, no només iniciar un túnel quan s’obre el correu. Un disparador d’activació per a un domini de correu pot aixecar la VPN en el moment adequat, però no defineix què passa mentre el túnel està caigut o després que falli.

Feu servir la política de bloqueig compatible del producte de punt final i delimiteu-ne l’abast deliberadament. Una regla a nivell d’aplicació cobreix cada compte d’aquella aplicació de correu, inclosos els personals. Una regla a nivell de destinació ha de nomenar els punts finals IMAP, d’enviament i d’autenticació del compte de feina, i ha de continuar funcionant quan aquestes adreces canviïn.

Cobriu les dues famílies d’adreces i les sessions existents. Una política que bloqueja connexions IPv4 noves mentre deixa IPv6 o un sòcol establert tranquil produeix sincronitzacions intermitents que semblen aleatòries. Els canvis de xarxa i els cicles de son formen part de la mateixa prova.

Les regles a nivell d’aplicació i de destinació tenen un abast diferent

Un bloqueig a nivell d’aplicació és senzill de raonar: cap trànsit del Correu surt sense el túnel. També és contundent, perquè la mateixa aplicació pot contenir un compte personal que no té res a veure amb la política. Els usuaris ho noten primer i ho reporten com una aplicació de correu espatllada.

Un bloqueig a nivell de destinació és més estret i més difícil de mantenir. Necessita el conjunt complet de punts finals que utilitza el compte, inclosos els serveis de descoberta i autenticació, i un procés per actualitzar-los. Si en falte un, el compte funciona a mitges; si n’incloeu massa, el correu no relacionat s’atura.

Trieu segons la redacció del requisit. «Aquest compte de feina no s’ha de connectar directament» apunta a l’abast de destinació. «Aquest Mac no ha de fer córrer el correu fora de la VPN» justifica la regla d’aplicació més àmplia, sempre que el propietari accepti l’efecte secundari sobre el compte personal.

Proveu el rebuig i l’absència per separat

Amb un compte de prova dedicat, connecteu-vos per la VPN i confirmeu el funcionament normal. Després desconnecteu-vos i proveu dues vegades: una per veure si el servidor rebutja l’inici de sessió i una per veure si el Mac intenta cap connexió. Són observacions diferents i pertanyen a registres diferents.

Mireu les proves del costat del client per a un SYN o una consulta DNS mentre esteu desconnectat, i el registre del servidor per a una sessió rebutjada o acceptada. Si el servidor rebutja però el client encara ho intenta, la regla del servidor funciona i falta la del client. Si el client no fa cap intent però el servidor encara accepta altres clients, la frontera és exactament on l’heu posada.

Anoteu el propietari de l’aplicació, l’adreça d’origen que el servidor veu realment i el compte de prova utilitzat. El proper canvi de xarxa o de proxy pot moure aquest origen, i una nota que anomeni el valor observat es comprova més de pressa que una altra ronda d’endevinalles.