Mail bereikt de server zonder VPN: waar de regel moet gelden

Mail blijft pollen en de VPN staat uit, maar het account synchroniseert nog steeds. De app doet wat ervoor is geconfigureerd; niets in een normaal mailprofiel zegt dat de server alleen via de tunnel bereikbaar is. Dat laat twee verschillende eisen over, en ze zijn makkelijk te verwarren: de dienst moet directe clients weigeren, of de Mac mag de poging helemaal niet doen.

Kies de eis voordat u een product kiest. Een serverregel en een clientregel falen op verschillende plekken, leveren verschillend bewijs en horen bij verschillende eigenaren. Beide toepassen is geldig wanneer beide uitspraken waar zijn, maar het ene vervangt het andere niet. Beide eisen zijn legitiem; ze zijn alleen niet dezelfde controle.

Het symptoom lijkt op de Mac, maar de server kan het lek zijn

Wanneer mail buiten de tunnel synchroniseert, begin dan met wat de server accepteert. Als de maillistener een directe verbinding vanaf internet beantwoordt, verandert geen enkele gemaksinstelling aan de clientkant dat feit. De Mac gedraagt zich normaal tegenover een dienst die nog open is.

Vraag de mailbeheerder welk bronadres de dienst ziet. Een VPN-gateway, reverse proxy of loadbalancer kan het clientadres vertalen, dus de adrespool in de VPN-configuratie komt misschien niet overeen met wat bij het mailproces aankomt. Een regel tegen de verkeerde bron blokkeert iedereen of niemand.

Dat antwoord vertelt ook of de dienst VPN-clients überhaupt kan onderscheiden. Als elke client via hetzelfde proxyadres binnenkomt, kan toelating op basis van bron ze niet scheiden, en moet de eis naar authenticatie of naar de clientkant verschuiven.

Toelating op de server: weiger de bron, niet de app

Een host- of netwerkfirewall kan de maillistener beperken tot goedgekeurde bronbereiken terwijl authenticatie en TLS ongewijzigd blijven. Een regelvoorwaarde die externe adressen, subnetten of bereiken matcht, is het gebruikelijke bouwblok; de exacte syntaxis hoort bij het firewallproduct van de server, niet bij de mailapp.

Dit is de sterkste grens wanneer de eis is „de dienst mag geen directe clients bedienen“. Hij houdt stand ook als de gebruiker een andere mailclient installeert, omdat de weigering vóór authenticatie plaatsvindt. Hij overleeft ook een Mac die zijn VPN-beleid negeert.

De grens ervan is even belangrijk. Een geweigerde verbinding bewijst dat de dienst de sessie weigerde; ze bewijst niet dat de Mac geen poging deed. DNS-resolutie, een TCP SYN naar een eerdere loadbalancer en een nieuwe poging na een fout kunnen allemaal gebeuren voordat de serverregel wordt bereikt. Als de eis over het openbaar maken van pogingen gaat en niet over toegang, is toelating op de server maar de helft van de controle.

Handhaving op de client: blokkeer de poging, niet alleen de tunnel

Een regel aan de clientkant moet het verkeer verbieden, niet alleen een tunnel starten wanneer mail wordt geopend. Een activeringstrigger voor een maildomein kan de VPN op het juiste moment omhoog brengen, maar bepaalt niet wat er gebeurt terwijl de tunnel uit staat of nadat hij faalt.

Gebruik het ondersteunde blokkeringsbeleid van het endpointproduct en bepaal de reikwijdte bewust. Een regel op appniveau dekt elk account in die mailapp, ook persoonlijke. Een regel op bestemmingsniveau moet de IMAP-, verzend- en authenticatie-eindpunten van het werkaccount benoemen, en moet blijven werken wanneer die adressen veranderen.

Dek beide adresfamilies en bestaande sessies. Een beleid dat nieuwe IPv4-verbindingen blokkeert maar IPv6 of een gevestigde socket met rust laat, levert periodieke synchronisaties op die willekeurig lijken. Netwerkwijzigingen en slaapcycli horen bij dezelfde test.

Regels op app- en bestemmingsniveau hebben een verschillende reikwijdte

Een blokkade op appniveau is eenvoudig te beredeneren: geen verkeer van Mail verlaat het toestel zonder de tunnel. Hij is ook grof, omdat dezelfde app een persoonlijk account kan bevatten dat niets met het beleid te maken heeft. Gebruikers merken dat als eerste en melden het als een kapotte mailapp.

Een blokkade op bestemmingsniveau is smaller en moeilijker te onderhouden. Hij heeft de volledige set eindpunten nodig die het account gebruikt, inclusief ontdekkings- en authenticatiediensten, en een proces om ze bij te werken. Mist er één, dan werkt het account half; neem je te veel op, dan stopt ongerelateerde mail.

Kies op basis van de formulering van de eis. „Dit werkaccount mag niet direct verbinden“ wijst op bestemmingsbereik. „Deze Mac mag geen mail buiten de VPN draaien“ rechtvaardigt de bredere appregel, mits de eigenaar het neveneffect voor het persoonlijke account accepteert.

Test weigering en afwezigheid apart

Verbind met een apart testaccount via de VPN en bevestig normale werking. Verbreek daarna en test twee keer: één keer om te zien of de server de aanmelding weigert, en één keer om te zien of de Mac überhaupt een verbinding probeert. Dat zijn verschillende waarnemingen en ze horen in verschillende logs.

Let op het bewijs aan de clientkant voor een SYN of een DNS-query terwijl u verbroken bent, en op het serverlog voor een geweigerde of geaccepteerde sessie. Als de server weigert maar de client nog steeds probeert, werkt de serverregel en ontbreekt de clientregel. Als de client niets probeert maar de server nog steeds andere clients accepteert, ligt de grens precies waar u hem hebt geplaatst.

Noteer de eigenaar van de handhaving, het bronadres dat de server werkelijk ziet en het gebruikte testaccount. De volgende netwerk- of proxywijziging kan die bron verplaatsen, en een notitie die de waargenomen waarde noemt, is sneller te controleren dan nog een ronde giswerk.