Mejlet når servern utan VPN: var regeln ska upprätthållas

Mejlet fortsätter att fråga och VPN är nere, men kontot synkroniseras ändå. Appen gör det den är konfigurerad för; ingenting i en vanlig mejlprofil säger att servern bara nås genom tunneln. Det lämnar två olika krav, och de är lätta att blanda ihop: tjänsten ska avvisa direkta klienter, eller så ska Macen aldrig försöka.

Välj kravet innan du väljer produkt. En serverregel och en klientregel misslyckas på olika ställen, ger olika bevis och tillhör olika ägare. Att tillämpa båda är giltigt när båda påståendena är sanna, men det ena ersätter inte det andra. Båda kraven är legitima; de är bara inte samma kontroll.

Symtomet ser ut som Macen, men servern kan vara läckan

När mejlet synkroniseras utanför tunneln, börja med vad servern accepterar. Om mejllyssnaren svarar på en direktanslutning från internet ändrar ingen bekvämlighetsinställning på klientsidan det faktumet. Macen beter sig normalt mot en tjänst som fortfarande är öppen.

Fråga mejladministratören vilken källadress tjänsten ser. En VPN-gateway, omvänd proxy eller lastbalanserare kan översätta klientadressen, så adresspoolen i VPN-konfigurationen stämmer kanske inte med det som når mejlprocessen. En regel skriven mot fel källa blockerar antingen alla eller ingen.

Det svaret säger också om tjänsten alls kan skilja på VPN-klienter. Om varje klient kommer via samma proxyadress kan källbaserat tillträde inte skilja dem, och kravet måste flyttas till autentisering eller till klientsidan.

Tillträde på servern: avvisa källan, inte appen

En värd- eller nätverksbrandvägg kan begränsa mejllyssnaren till godkända källområden medan autentisering och TLS förblir oförändrade. Ett regelvillkor som matchar fjärradresser, subnät eller områden är den vanliga byggstenen; den exakta syntaxen tillhör serverns brandväggsprodukt, inte mejlappen.

Detta är den starkaste gränsen när kravet är ”tjänsten ska inte betjäna direkta klienter”. Den håller även om användaren installerar en annan mejlklient, eftersom avvisningen sker före autentisering. Den överlever också en Mac som ignorerar sin VPN-policy.

Dess gräns är lika viktig. En avvisad anslutning bevisar att tjänsten avvisade sessionen; den bevisar inte att Macen inte försökte. DNS-uppslagning, ett TCP SYN till en tidigare lastbalanserare och ett nytt försök efter fel kan alla ske innan serverns regel nås. Om kravet handlar om att avslöja försök och inte om åtkomst är tillträde på servern bara halva kontrollen.

Upprätthållande på klienten: blockera försöket, inte bara tunneln

En regel på klientsidan måste förbjuda trafiken, inte bara starta en tunnel när mejlet öppnas. En aktiveringsutlösare för en mejldomän kan lyfta VPN:en i rätt ögonblick, men den definierar inte vad som händer medan tunneln är nere eller efter att den misslyckas.

Använd slutpunktsproduktens stödda blockeringspolicy och avgränsa dess omfattning medvetet. En regel på appnivå täcker varje konto i den mejlappen, även personliga. En regel på destinationsnivå måste namnge IMAP-, sändnings- och autentiseringsslutpunkterna för arbetskontot, och den måste fortsätta fungera när dessa adresser ändras.

Täck båda adressfamiljerna och befintliga sessioner. En policy som blockerar nya IPv4-anslutningar men lämnar IPv6 eller en etablerad socket i fred ger periodiska synkroniseringar som verkar slumpmässiga. Nätverksändringar och sömncykler är en del av samma test.

Regler på app- och destinationsnivå har olika räckvidd

En blockering på appnivå är enkel att tänka igenom: ingen trafik från Mejl lämnar enheten utan tunneln. Den är också grov, eftersom samma app kan innehålla ett personligt konto som inte har något med policyn att göra. Användare märker det först och rapporterar det som en trasig mejlapp.

En blockering på destinationsnivå är smalare och svårare att underhålla. Den behöver hela uppsättningen slutpunkter som kontot använder, inklusive upptäckts- och autentiseringstjänster, och en process för att uppdatera dem. Ett saknas och kontot fungerar halvt; tar du med för många stoppar orelaterad mejl.

Välj efter kravers formulering. ”Detta arbetskonto ska inte ansluta direkt” pekar på destinationsomfång. ”Denna Mac ska inte köra mejl utanför VPN:en” motiverar den bredare appregeln, förutsatt att ägaren accepterar bieffekten för det personliga kontot.

Testa avvisning och frånvaro separat

Med ett dedikerat testkonto, anslut via VPN:en och bekräfta normal drift. Koppla sedan från och testa två gånger: en gång för att se om servern avvisar inloggningen, och en gång för att se om Macen alls försöker en anslutning. Det är olika observationer och de hör hemma i olika loggar.

Titta efter bevis på klientsidan för ett SYN eller en DNS-fråga medan du är frånkopplad, och i serverloggen efter en avvisad eller accepterad session. Om servern avvisar men klienten fortfarande försöker fungerar serverregeln och klientregeln saknas. Om klienten inte försöker men servern fortfarande accepterar andra klienter är gränsen exakt där du placerade den.

Notera ägaren av upprätthållandet, källadressen som servern faktiskt ser och testkontot som användes. Nästa nätverks- eller proxyändring kan flytta den källan, och en anteckning som namnger det observerade värdet är snabbare att kontrollera än ännu en runda gissningar.