Mail når serveren uden VPN: hvor reglen skal håndhæves

Mail bliver ved med at polle, og VPN er nede, men kontoen synkroniserer stadig. Appen gør, hvad den er sat til; intet i en normal mailprofil siger, at serveren kun kan nås gennem tunnelen. Det efterlader to forskellige krav, og de er nemme at blande sammen: tjenesten skal afvise direkte klienter, eller Mac’en skal slet ikke forsøge.

Vælg kravet, før du vælger et produkt. En serverregel og en klientregel fejler forskellige steder, giver forskellige beviser og hører til forskellige ejere. At anvende begge er gyldigt, når begge udsagn er sande, men det ene erstatter ikke det andet. Begge krav er legitime; de er bare ikke den samme kontrol.

Symptomet ligner Mac’en, men serveren kan være lækken

Når mail synkroniserer uden for tunnelen, så start med, hvad serveren accepterer. Hvis mail-lytteren svarer på en direkte forbindelse fra internettet, ændrer ingen bekvemmelighedsindstilling på klientsiden den kendsgerning. Mac’en opfører sig normalt over for en tjeneste, der stadig er åben.

Spørg mailadministratoren, hvilken kildeadresse tjenesten ser. En VPN-gateway, omvendt proxy eller load balancer kan oversætte klientadressen, så adressepuljen i VPN-konfigurationen passer måske ikke med det, der når mailprocessen. En regel skrevet mod den forkerte kilde blokerer enten alle eller ingen.

Det svar fortæller også, om tjenesten overhovedet kan skelne VPN-klienter. Hvis hver klient ankommer gennem den samme proxyadresse, kan kildebaseret adgang ikke skille dem, og kravet må flyttes til autentificering eller til klientsiden.

Serveradgang: afvis kilden, ikke appen

En værts- eller netværksfirewall kan begrænse mail-lytteren til godkendte kildeområder, mens autentificering og TLS forbliver uændret. En regelbetingelse, der matcher fjernadresser, undernet eller områder, er den sædvanlige byggeklods; den præcise syntaks hører til serverens firewallprodukt, ikke til mailprogrammet.

Det er den stærkeste grænse, når kravet er »tjenesten må ikke betjene direkte klienter«. Den holder, selv hvis brugeren installerer en anden mailklient, fordi afvisningen sker før autentificering. Den overlever også en Mac, der ignorerer sin VPN-politik.

Dens grænse er lige så vigtig. En afvist forbindelse beviser, at tjenesten afviste sessionen; den beviser ikke, at Mac’en ikke forsøgte. DNS-opslag, et TCP SYN til en tidligere load balancer og et nyt forsøg efter fejl kan alle ske, før serverens regel nås. Hvis kravet handler om at afsløre forsøg snarere end om adgang, er serveradgang kun halvdelen af kontrollen.

Håndhævelse på klienten: bloker forsøget, ikke bare tunnelen

En regel på klientsiden skal forbyde trafikken, ikke bare starte en tunnel, når mail åbnes. En aktiveringsudløser for et maildomæne kan rejse VPN’en på det rigtige tidspunkt, men den definerer ikke, hvad der sker, mens tunnelen er nede, eller efter den fejler.

Brug endpoint-produktets understøttede blokeringspolitik, og afgræns dens omfang bevidst. En regel på appniveau dækker hver konto i det mailprogram, inklusive personlige. En regel på destinationsniveau skal navngive arbejdskontoens IMAP-, afsendelses- og autentificeringsendpoints, og den skal blive ved med at virke, når disse adresser ændres.

Dæk begge adressefamilier og eksisterende sessioner. En politik, der blokerer nye IPv4-forbindelser, men lader IPv6 eller en etableret socket være, giver periodiske synkroniseringer, der virker tilfældige. Netværksændringer og søvncyklusser er en del af den samme test.

Regler på app- og destinationsniveau har forskellig rækkevidde

En blokering på appniveau er let at gennemskue: ingen trafik fra Mail forlader enheden uden tunnelen. Den er også grov, fordi det samme program kan have en personlig konto, der intet har med politikken at gøre. Brugerne bemærker det først og rapporterer det som en ødelagt mailapp.

En blokering på destinationsniveau er smallere og sværere at vedligeholde. Den kræver det fulde sæt endpoints, som kontoen bruger, inklusive opdagelses- og autentificeringstjenester, og en proces til at opdatere dem. Mangler man ét, virker kontoen halvt; medtager man for mange, stopper urelateret mail.

Vælg efter kravers formulering. »Denne arbejdskonto må ikke forbinde direkte« peger på destinationsomfang. »Denne Mac må ikke køre mail uden for VPN’en« begrunder den bredere appregel, forudsat at ejeren accepterer bivirkningen for den personlige konto.

Test afvisning og fravær hver for sig

Med en dedikeret testkonto, forbind gennem VPN’en og bekræft normal drift. Afbryd derefter og test to gange: én gang for at se, om serveren afviser loginet, og én gang for at se, om Mac’en overhovedet forsøger en forbindelse. Det er forskellige observationer, og de hører i forskellige logs.

Hold øje med klientsidens beviser for et SYN eller en DNS-forespørgsel, mens du er afbrudt, og med serverloggen for en afvist eller accepteret session. Hvis serveren afviser, men klienten stadig forsøger, virker serverreglen, og klientreglen mangler. Hvis klienten ikke forsøger, men serveren stadig accepterer andre klienter, er grænsen præcis, hvor du placerede den.

Noter håndhævelsesejeren, den kildeadresse serveren faktisk ser, og den anvendte testkonto. Den næste netværks- eller proxyændring kan flytte den kilde, og en note, der navngiver den observerede værdi, er hurtigere at tjekke end endnu en runde gætteri.