ZusewayCleveres Tool, sauberer Ansatz: per Domain/IP am System-Routing drehen und die lokale Kiste atmen lassen, statt Musikstreams und AirPlay durch den Firmen-Trichter zu quetschen. Für private Macs und „normale“ VPNs funktioniert das oft erstaunlich gut.
Das Aber kommt mit Zscaler & Co.: Viele Unternehmen erzwingen keinen reinen Full-Tunnel, sondern einen Proxy/PAC-gestützten Pfad mit SSL-Inspection. Dann läuft der Verkehr nicht über die Default-Route, sondern über die heilige PAC-Datei. Routing-Ausnahmen greifen dort schlicht nicht. Ergebnis: Egal wie viel man am Route-Table poliert, der Proxy sagt trotzdem „nein“.
Kurzdiagnose für den Zscaler-Frust:
– Wenn networksetup -getautoproxyurl/-getwebproxy etwas liefert: Proxyland. Bypass nur über „Kein Proxy für …“ (MDM-gesperrt? Dann Feierabend).
– Wenn die Default-Route auf ein utun-Interface zeigt (netstat -rn): echtes Tunneling. Dann können statische Routen helfen – bis das CDN die IP wechselt.
– DNS ist ein zweiter Hebel: Wenn die Firmen-DNS-Server erzwungen werden (scutil –dns), gehen Domain-basierte Ausnahmen oft ins Leere. Ohne eigene Resolver keine Chance.
– Testweise: curl –noproxy „*“ https://… zeigt, ob eine App am Systemproxy hängt. Browser tun das fast immer.
Per-App-Bypass? Unter macOS ohne gemanagte Network-Extensions praktisch nicht robust machbar. Domainlisten? Nützlich, aber gegen dynamische CDNs so stabil wie ein Post-it im Sturm.
Organisatorisch bleibt’s nüchtern: Auf Firmengeräten mit Admin-Sperren gewinnt die Compliance-Engine. Wer Privates flüssig und stressfrei streamen will, nutzt ein separates, nicht verwaltetes Gerät oder bittet offiziell um Split-Tunnel-Ausnahmen. Ja, dauert. Nein, Routentricks schlagen keine Richtlinie.
Fazit: VPN Bypass ist ein gutes Werkzeug für die Fälle, in denen Physik (Routing) noch gilt. In Proxy-Umgebungen regiert Politik (Compliance). Und gegen eine PAC-Datei mit Gottesgnadentum hilft nur: nicht daran hängen.
