Anleitungen

Zielgruppe und Zweck

Dieses Dokument ist für Netzwerk- und Sicherheits-IT-Administratoren konzipiert, die über Grundkenntnisse in Netzwerktechnik und VPN-Technologien verfügen.

Als Next-Generation-Sicherheits- und Netzwerkprodukt verhält sich Jamf Connect ZTNA erheblich anders als ein herkömmliches VPN. Dieser Leitfaden soll Administratoren helfen, die Grundlagen des Produktdesigns zu verstehen, um bei Planung, Bereitstellung, Wartung und Fehlerbehebung zu unterstützen.

Dieser Leitfaden ist keine Produktdokumentation, die beschreibt, wie man Jamfs ZTNA-Produkt konfiguriert, sondern erklärt, wie es funktioniert, damit Sie das Verhalten des Produkts in Ihrer Umgebung vorhersagen und verstehen können. Wenn Sie nach Dokumentation suchen, finden Sie diese in unserer Jamf Connect ZTNA-Dokumentation, oder wenn Sie zunächst ein technisches Videoübersicht des Produkts ansehen möchten, schauen Sie sich die JNUC 2021 Jamf ZTNA Deep Dive-Präsentation an.

Wir empfehlen Ihnen dringend, diesen Leitfaden zu lesen (und als Lesezeichen zu speichern!), wenn Sie Jamf Connect ZTNA in produktiver Kapazität in Ihrer Organisation einsetzen.

Übersicht

Jamfs ZTNA-Produkt wurde von Anfang an konzipiert, um der Cloud Security Alliance (CSA) Software Defined Perimeter (SDP)-Architektur zu entsprechen. Diese Architektur verkörpert viele der Prinzipien der breiteren Industrie-Definition von Zero Trust Network Access (ZTNA), einschließlich Least Privileged Access, rollenbasierter Zugriff, Multi-Faktor-Identitätsverifizierung, Device Trust und vielem mehr. Das Produkt wurde ursprünglich von Wandera entwickelt und im Juli 2021 in die Jamf-Sicherheitsplattform integriert.

Obwohl Jamf Connect ZTNA viele der gleichen Ergebnisse wie ein herkömmliches VPN teilt – wie beispielsweise die Verfügbarkeit von Remote-Ressourcen, wenn die VPN-Schnittstelle online geht – sind die tatsächlichen Mechaniken zur Unterstützung dieser Ergebnisse vollständig unterschiedlich. Dies ist das Ergebnis davon, wie Connect ZTNA IP-Adressen, DNS und Cloud-Technologien nutzt, um Client-zu-Server-Routing bereitzustellen, das einen Quantensprung bei Leistung, Skalierbarkeit und Sicherheit im Vergleich zu herkömmlichen VPN-Architekturen darstellt.

Beginnen wir also mit einem der bedeutendsten und wichtigsten Unterschiede zwischen dem Jamf SDP und einem herkömmlichen VPN: Connection Brokering versus Routing.

Connection Brokering

Zunächst: Nehmen Sie alles, was Sie über die Funktionsweise eines VPN wissen und annehmen, und stellen Sie es beiseite. Obwohl das endgültige Paket-Routing letztendlich einem herkömmlichen VPN ähnelt, gibt es ein völlig neues Verarbeitungselement im Verbindungsprozess.

Herkömmliches VPN

Wenn ein Gerät eine Verbindung zu einem herkömmlichen VPN herstellt, erstellt es einen sicheren Tunnel mit einem VPN-Konzentrator, der sich lokal oder in der Cloud befinden kann und von Ihnen selbst oder einem Service-Provider betrieben wird.

Unabhängig davon, wo sich der Konzentrator befindet oder wer ihn betreibt, ist das allgemeine Verhalten gleich:

1. Das Gerät authentifiziert sich beim VPN-Konzentrator und ein sicherer Tunnel wird hergestellt, der eine virtuelle Netzwerkschnittstelle am Endpunkt erstellt.
2. Dem Gerät wird vom Konzentrator dynamisch eine IP-Adresse zugewiesen, die für die Lebensdauer dieses Tunnels gültig ist (manchmal kann sie durch DHCP-Bindung „statisch" neu zugeordnet werden).
3. Für die virtuelle Netzwerkschnittstelle werden eine oder mehrere Routen konfiguriert, die die Netzwerk-Subnetze definieren, die dem Unternehmen gehören und über das VPN weitergeleitet werden sollten. Ein Full-Tunnel-VPN leitet den gesamten Datenverkehr vom Gerät zum Konzentrator weiter und eliminiert alle lokalen Netzwerkzugriffe.
4. Ein DNS-Nameserver wird auf dem Gerät konfiguriert, der normalerweise auf der anderen Seite des VPN im Kundennetzwerk ansässig ist.
5. Immer wenn eine App eine Anfrage an eine Ressource stellt, wird DNS zu einer IP-Adresse aufgelöst und der Datenverkehr wird über das VPN weitergeleitet, wenn die IP-Adresse des Pakets innerhalb einer der Routen der VPN-Schnittstelle liegt.
6. Der VPN-Konzentrator leitet das Paket in das Kundennetzwerk weiter. In einigen Fällen werden Firewall-Zugriffskontrolllisten im gesamten Netzwerk implementiert, um die Zugriffskontrolle zu beschränken.

Während dies sicherlich funktioniert, besteht das grundlegende Sicherheitsproblem dieser Architektur darin, dass alle Ressourcen innerhalb der weitergeleiteten Subnetze dem Gerät im Wesentlichen zur Verfügung stehen. Dies ermöglicht die Konnektivität zu IT-Services und Servern, mit denen die meisten Endpunkte keine Verbindung herstellen sollten. Wenn Sie ein Angreifer sind und das Endgerät erfolgreich ausnutzen können, können Sie diese VPN-Verbindung nutzen, um schwache Punkte auf Servern zu finden, die „sicher" hinter der Firewall liegen und möglicherweise nicht vollständig gepatcht oder anderweitig ordnungsgemäß gesichert sind.

Sicherlich können Sie Zugriffskontrollregeln im Netzwerk implementieren, aber das ist schwierig und fehleranfällig. Normalerweise müssen solche Regeln auf der IP-Adressebene verwaltet werden, daher sind sie anfällig und gefährlich zu ändern. Dies führt zu Netzwerk-Sicherheitsrichtlinien, die schnell von der erforderlichen Änderungsrate für neue und sich entwickelnde Anwendungen, die unternehmenskritisch sind, überholt werden. Sie haben auch keine gute Möglichkeit, Monitoring und Audit-Berichte so zu überwachen, dass die Benutzeridentität eng mit ihren Verbindungen gekoppelt ist. Was tun also die meisten Organisationen? Sie lassen es offen und nähen die Berichte zusammen, wenn es einen Vorfall gibt.

Wie beheben Sie diese Herausforderungen? Betreten Sie SDP und „vermittelte" Netzwerkverbindungen.

SDP: Connection Brokering

Wenn Jamf's ZTNA auf einem Endpunktgerät verbunden ist, gibt es von Anfang an einige bedeutende Unterschiede:

1. Eine zustandslose WireGuard-Netzwerkschnittstelle wird nach einem sehr leichten initialen Handshake am Endpunkt erstellt. Hinweis: Je nach Ihrer ZTNA-Bereitstellung können Apple-Geräte HTTP/3 anstelle von WireGuard verwenden.
2. Ein einfacher Satz von IPv6-Routen – ausgehandelt außerhalb der Schnittstellenherstellung – wird für die VPN-Netzwerkschnittstelle konfiguriert. Standardmäßig gehören diese Routen nicht dem Kunden, sondern sind reservierte IPv6-Bereiche, die von Jamf verwaltet werden (fd53:1c5a::/32, fddd:dddd::/128). Der VPN-Netzwerkschnittstelle wird auch eine statische IPv6-Adresse zugewiesen, die ebenfalls außerhalb der Schnittstellenherstellung ausgehandelt wurde. Es werden standardmäßig keine IPv4-Adressen oder -Routen der VPN-Netzwerkschnittstelle zugewiesen!
3. Ein von Jamf verwalteter DNS-Nameserver fddd:dddd:: wird auf dem Gerät konfiguriert.

Wow. Was? Ja, Sie haben richtig gelesen: keine unternehmensinternen IP-Adressen, Subnetze oder DNS-Nameserver werden in der Routing-Tabelle des Endbenutzergeräts veröffentlicht. Nicht mal irgendwelche IPv4-Adressen! Dies ist ein wichtiger Baustein des SDP-Connection-Brokering, damit der Endpunkt und der Benutzer sich der internen Netzwerktopologie nicht bewusst sind und nicht versuchen können, mit internen Netzwerk-IPs zu verbinden, selbst wenn sie wollten.

Wie verbindet sich eine Anwendung auf dem Gerät also mit einer App auf einem Server, der sich in einem dieser internen IPv4-Subnetze befindet? Hier kommt Connection Brokering zum Einsatz, ermöglicht durch die Magie von DNS, NAT und Jamf-Routing-Technologien.

Info: Hinweis zum direkten IP- und Subnetzzugriff

Neben den Sicherheitsvorteilen der Nichtveröffentlichung interner Subnetze für Endpunkte – noch weniger irgendwelche IPv4-Adressen – hilft dies auch, Netzwerksegmentüberlappungen zu vermeiden, die Benutzer in nicht-unternehmensgesteuerten Netzwerken erleben könnten (z. B. zu Hause, in Cafés usw.). Dies ist entscheidend für die Ermöglichung nahtloser Remote-Work-from-Anywhere-Funktionalität.

Es gibt jedoch einige spezifische Anwendungsfälle, in denen eine IPv4-Adresse oder ein Subnetz direkt nutzbar sein muss und nicht auf DNS-basiertes Connection Brokering angewiesen sein kann. Für diese Situationen unterstützt Connect ZTNA die Konfiguration von „Direct IP"-Zugriff. Weitere Details finden Sie im Abschnitt „Brokered Connections Exceptions" dieses Leitfadens.

Nehmen wir an, der Benutzer versucht, sich mit App zu verbinden, die sich unter app.acmeinc.com befindet und eine interne IP-Adresse von 10.0.1.22 hat. Folgendes geschieht, um diese Verbindung von einem Jamf ZTNA-fähigen Gerät zu ermöglichen (das folgende Beispiel zeigt eine TCP-Verbindung zur Ziel-App, aber ein ähnlicher Ablauf wird auch für UDP-Verbindungen verwendet):

1. Der Benutzer initiiert eine Verbindung zu app.acmeinc.com über seinen Browser oder eine native App seiner Wahl.
2. Die App fordert das Betriebssystem auf, diesen Hostnamen zu einer IP-Adresse aufzulösen, um eine Verbindung herzustellen. Mit aktivem Jamf Connect ZTNA ist der zu verwendende DNS-Nameserver fddd:dddd::, eine virtuelle IPv6-Adresse, die an die Jamf Connect ZTNA-Policy-Engine gebunden ist.
3. Das Betriebssystem stellt eine Reihe von DNS-Anfragen an fddd:dddd:: für app.acmeinc.com, einschließlich der Typen A, AAAA und HTTPS.
4. Der Jamf Connect ZTNA DNS-Nameserver führt ein Upstream-Lookup des FQDN durch und prüft zunächst, ob eine Custom DNS Zone für die Domain konfiguriert wurde (*.acmeinc.com mit 10.0.1.10 als autorisierendem Nameserver in diesem Beispiel). Wenn keine Custom DNS Zone gefunden wird, nutzt der Service eine Reihe öffentlicher Upstream-DNS-Resolver.
   1. Hinweis: Der Service fordert nur einen Upstream-A-Datensatz an, während AAAA und HTTPS derzeit ignoriert werden. Dies ist nur ein potenzielles Problem für Server, die nur über IPv6 erreichbar sind, was heute in den meisten öffentlichen und privaten Netzwerken äußerst selten ist.
5. Nach Erhalt der A-DNS-Antworten von einem autorisierendem Server (in diesem Fall A 10.0.1.22 vom internen Nameserver des Kunden über eine Custom DNS Zone-Konfiguration) identifiziert der Jamf Connect ZTNA DNS-Nameserver den Benutzer und das Gerät, das die Ressource anfordert, und sucht nach einer entsprechenden Access Policy, die app.acmeinc.com als Datenverkehrs-Matching-Kriterium definiert.
   1. Diese Access Policy bewertet die Gruppenmitgliedschaft des Benutzers und die Device-Integrität, um zu bestimmen, ob der Zugriff auf die Ressource gewährt werden sollte.
   2. Auch in der Policy definiert ist, wie der Datenverkehr über die Jamf-Cloud weitergeleitet werden sollte. In diesem Fall gehen wir davon aus, dass der Kunde ein IPSec Interconnect Gateway konfiguriert hat, um als private Route zu dieser internen App zu dienen.
6. Angenommen, die Access Policy wird gefunden und das Gerät und der Benutzer erfüllen alle Kriterien, die erforderlich sind, um eine Verbindung zu der Ressource herzustellen. Die Jamf Connect ZTNA-Routing-Fabric erstellt eine „Cloud-Flow-Mapping", die eine kurzlebige IPv6 innerhalb des an den Endpunkt veröffentlichten reservierten IPv6-Subnetzes zuweist (z. B. fd53:1c5a::aaaa:bbbb ↔ 10.0.1.22).
   1. Dieser Flow ist eindeutig pro Verbindung und Benutzer und kann nicht über seine Lebensdauer hinaus oder von einem anderen Gerät wiederverwendet werden.
7. Diese IPv6-Adresse fd53:1c5a::aaaa:bbbb wird an den Endpunkt als AAAA-DNS-Antwort zurückgegeben.
   1. Der Service gibt standardmäßig keine A- oder HTTPS-Antwort zurück! Dies ist beim Troubleshooting von DNS-Antworten mithilfe von Utilities wie dig sehr wichtig zu beachten!
8. Ein neuer Socket zu fd53:1c5a::aaaa:bbbb wird erstellt, und da diese IP innerhalb des Subnetzes liegt, das der Jamf Connect ZTNA VPN-Netzwerkschnittstelle zugeordnet ist, wird dieser Socket und alle nachfolgenden Pakete über einen WireGuard-Tunnel an die Jamf Security Cloud weitergeleitet.
9. Nach Erhalt des Pakets führt die Jamf Connect ZTNA-Routing-Fabric zusätzliche Sicherheitsprüfungen durch und lokalisiert das Cloud-Flow-Mapping für die IPv6-Zieladresse.
10. Die Jamf Connect ZTNA-Routing-Fabric leitet die Pakete über das globale Cloud-Backbone weiter, erreicht letztendlich das IPSec Interconnect, wie durch die Access Policy definiert. Bevor das Paket über den IPSec-Tunnel weitergeleitet wird, findet gemäß des Cloud-Flow-Mapping eine NAT64-Translation statt, was ein Paket mit der ursprünglichen IPv4-Adresse (10.0.1.22) als Ziel-IP ergibt.
    1. Die Quell-IP des Pakets wird auf eine IP-Adresse innerhalb des in der IPSec-Konfiguration definierten Subnetzes gesetzt. Der gesamte an das Kundennetzwerk gesendete Datenverkehr wird von einer Pseudo-Zufalls-IP innerhalb dieses Subnetzes angezeigt.
    2. Wenn Sie ein regionales Datencenter für Cloud-basierte NAT-Egress verwenden, wird die Quell-IP dynamisch über die globalen IP-Adressen dieses Datencenters load-balanced.
11. Alle entsprechenden Brokered Connections werden für den Benutzer, das Gerät und die Anwendung protokolliert und sind zur Überprüfung im Access Event Log in RADAR sowie in anderen Berichten verfügbar.

Wie Sie sehen, gibt es eine enge Kopplung von DNS, IP-Routing und NAT, die in herkömmlichen VPN-Konfigurationen einfach nicht nativ existiert.

Trotz dieser Unterschiede behandelt Jamf Connect ZTNA Pakete äußerst effizient, da alles Routing nativ auf Layer 3 stattfindet und Real-Time-Anwendungen wie VoIP und Video problemlos unterstützt. Da alle Encapsulation mit dem ultra-schnellen und effizienten WireGuard- oder HTTP/3 UDP-Encapsulation-Protokoll erfolgt, gibt es keine Transmission-Protokoll-„Zusammenbrüche", die häufig beim Routing von TCP-Verbindungen innerhalb eines TCP/mTLS-basierten Tunnels in Netzwerken mit Paketverlusten auftreten.

Info: SDP, VPN und End-to-End-App-Verschlüsselung

Jamf Connect ZTNA wurde entwickelt, um schnelle und dynamische Software-Defined-Networking-Funktionen unter Verwendung moderner Packet-Encapsulation- und Verschlüsselungstechnologien bereitzustellen, damit Sie Datenverkehr von Endpunkten zu praktisch jeden Ziel mit wenigen Klicks in einer Web-Oberfläche einfach lenken und Richtlinien anwenden können.

Jedoch können Jamf und andere VPN-Technologien, die Datenverkehr im Flug verschlüsseln, keine echte End-to-End-Verschlüsselung von Client-Anwendung zu Server-Anwendung bereitstellen.

Daher müssen Sie für alle Apps, die sensible Daten enthalten, IMMER solche Anwendungen so konfigurieren, dass sie App-Level-Verschlüsselungstechnologien wie HTTPS oder TLS verwenden. Dies ist jetzt Standard-Praxis für alle Anwendungen. Dies ist der einzige Weg, um sicherzustellen, dass ein Unbefugter zu keinem Zeitpunkt in Jamf- oder Kundennetzwerk Zugriff erhält.

Diese Connection-Brokering-Technik hat sich auf der Jamf ZTNA-Plattform als funktionsfähig auf Unternehmensleistung und -skalierung erwiesen. Alle modernen Betriebssysteme unterstützen nativ IPv6 (auch wenn das Gerät nur eine IPv4-Netzwerkverbindung hat), und die überwiegende Mehrheit der Anwendungen und Benutzer unterstützen IPv6 und verwenden DNS für alle ihre Verbindungen.

Das ist allerdings nicht der Fall für die, die das nicht tun... dann müssen Sie spezielle Konfigurationen für diese Ausreißer definieren, damit sie über Connect ZTNA funktionieren.

Verfügbarkeit und Failover

Jamf ZTNA ist mit Überlegungen zur Netzwerkpartitionierung und Geräten, die keine Verbindung zur Jamf Security Cloud herstellen können, architekt. Dies erfolgt durch verschiedene sich überlappende Methoden:

Dead Gateway Detection

Jamf Trust kann gefährliche oder instabile Verbindungen erkennen, die häufig aus unsicheren Captive Portals resultieren. Diese Captive Portals können den Datenverkehr abfangen, was zu Konnektivitätsproblemen führt.

Mit Dead Gateway Detection (DGD) kann die Jamf Trust-App Benachrichtigungen auf Endbenutzergeräten zum aktuellen Zustand ihrer Verbindung bereitstellen. DGD nutzt allgemeine Konnektivitätsprüfungen, wie Captive-Portal- und Web-Konnektivitätsprüfungen, während Zero Trust Network Access (ZTNA)-Endpunktauflösungen verwendet werden, um ein Dead Gateway zu erkennen. Um DGD direkt zu unterstützen, verhindert der Bypass-Modus in Jamf Trust, dass gefährlicher Datenverkehr durch den VPN-Tunnel fließt. Dies ermöglicht Endbenutzern, sicher im Internet zu surfen, ohne ihr VPN oder ihre Arbeitsanwendungen.

Load-balanced und regionale Ingress-Standorte

Nach Erkennung einer aktiven Verbindung fordert Jamf Trust lokale IP-Endpunkte an, die vom lokalen DNS-Provider des Netzwerks ermittelt wurden (normalerweise von DHCP bereitgestellt). Die TTL (Time-to-Live) für diese Endpunkte beträgt 60 Sekunden. Sollte einer dieser Endpunkte nicht verfügbar werden, wird er innerhalb von 60 Sekunden aus dem Pool entfernt. Dies führt zu einer RTO (Recovery Time Objective) von bis zu 60 Sekunden, aber in Kombination mit Dead Gateway Detection ist die Wiederherstellung aus einem einzelnen Endpunkt-Ausfall sofort.

Local policy caching

Wie im Abschnitt SDP: Connection Brokering beschrieben, nutzt Jamf lokale DNS-Surrogate, um Geräte-Datenverkehr zur geeigneten Ressource umzuleiten. Diese lokalen DNS-Einträge haben auch eine TTL von 60 Sekunden. Sollte eine Policy-Änderung vorgenommen werden (entweder automatisch aufgrund von risikobasierter Policy oder aufgrund einer Verwaltungsänderung), beträgt der längste Zeitraum vor einem Policy-Update lokal auf dem Gerät 60 Sekunden. Hinweis: Die Policy lebt nicht lokal auf dem Gerät, aber aufgrund von DNS-Caching kann es scheinen, dass ein Policy-Update alle 60 Sekunden übertragen wird.

Brokered Connections Exceptions

Während die meisten Apps und Services nativ und ohne besondere Überlegung über den Jamf ZTNA-Service funktionieren, gibt es einige spezifische Anwendungsfälle und Anwendungsklassen, die Konnektivität erfordern, die von der Brokered-Connection-Methode nicht unterstützt wird.

Apps/Services, die DNS nicht verwenden

Wie Sie oben gelernt haben, wird das einfach nicht funktionieren, wenn eine App oder ein Benutzer keinen FQDN für die Verbindung zu einer Ressource verwendet.

Das liegt daran, dass ohne eine DNS-Anfrage, um die Verbindung zu starten, eine Brokered IPv6-Adresse niemals ausgegeben wird. Und da die IPv4-Adresse des Ziels nicht in der Routing-Tabelle des Geräts hinzugefügt wird, wird dieses Paket einfach ins Internet gehen und nie zurückkommt.

Dies ist in aggregierter Form selten, aber Verbindungsszenarios, die keine FQDNs/DNS beinhalten, sind häufig für:

• IT-Administratoren, die direkt mit Netzwerkgeräten verbunden sind
• Entwickler, die sich mit neuen Instanzen virtueller Instanzen verbinden, die nicht bei DNS registriert sind
• Legacy-Anwendungen, die sich über eine IPv4-Adresse und nicht FQDN verbinden

Aus diesem Grund unterstützt Jamf Connect ZTNA die optionale Definition von „Direct IPs and Subnets" in einer App's Access Policy.

Error: Sicherheit und Direct IP- und Subnet-Exceptions

Wir empfehlen nur, IP-basierten Zugriff für die Benutzer und Apps zu konfigurieren, die absolut auf diese Weise auf Ressourcen zugreifen müssen. Und wenn Sie sie konfigurieren, werden die definierten Subnetze so eng wie möglich definiert (z. B. 10.0.1.0/29) vs. (10.0.0.0/16).

Das liegt daran, dass Sie durch die Etablierung des Routing auf einem so breiten Level die meisten Sicherheitsvorteile des Brokered-Connectivity-Modells negieren und zu dem Verhalten eines herkömmlichen VPN zurückgreifen. Dies lässt Ihre Organisation für die gleichen Arten von Angriffen anfällig, die herkömmliche VPNs beeinflussen, die durch die Aktivierung übermäßigen Zugriffs auf Netzwerkressourcen verursacht werden.

Wenn Sie auf diese Weise eine oder mehrere IP-Adressen konfigurieren, werden die definierten CIDR-Subnetze in der Routing-Tabelle der Geräte veröffentlicht, die dieser Policy zugeordnet sind. Dies bedeutet, dass zusätzlich zum Standard-fd53 IPv6-Subnetz die VPN-Netzwerkschnittstelle auch alle IPv4-Subnetze enthält, die in allen anwendbaren Access Policies definiert sind.

Nach dem Speichern einer Access Policy mit definierten IP-Adressen kann es bis zu 30 Minuten dauern, bis diese Änderungen an alle Geräte verbreitet werden. Das Aktivieren und Deaktivieren von Jamf Connect ZTNA triggert ein sofortiges Update dieser Policies.

Angenommen, eine 10.0.1.22 wurde zur gleichen App Access Policy hinzugefügt, ein Jamf ZTNA-Endbenutzer könnte sich via http://10.0.1.22 oder ping 10.0.1.22 verbinden.

Es ist erwähnenswert, dass die Fähigkeit, sich mit der Ressource zu verbinden, auch wenn die Verbindung nicht über DNS vermittelt wird, immer noch allen in der Access Policy definierten Bedingungen unterliegt.

Apps, die FQDN verwenden, aber IPv6 nicht unterstützen

Es gibt eine Teilmenge von Anwendungen, die aus verschiedenen Gründen einfach nicht mit IPv6 zurecht kommen:

• Einige moderne Anwendungen haben komplexe/benutzerdefinierte Networking-Stacks, die einfach nicht mit IPv6 kompatibel sind (z. B. Docker für macOS)
• Legacy-Anwendungen, die nicht wissen, dass IPv6 existiert, und keine AAAA-Antwort nutzen können und fehlschlagen, wenn es keine A-Antwort gibt.

Für diese Anwendungen können Sie eine Access Policy so konfigurieren, dass sie „Compatible" Routing statt „Optimized" verwendet. Dies führt zu folgendem:

• Endpunkte, die dieser Access Policy unterliegen, werden ein Jamf Cloud-Unique-IPv4-Subnetz übertragen, das identisch mit dem IPv6-Bereich für Connection Brokering funktioniert
  • Dieser gleiche Bereich wird für eine oder mehrere auf diese Weise konfigurierte Access Policies verwendet.
  • Es kann bis zu 10 Minuten dauern, bis diese neue Route an alle Geräte verbreitet wird, oder das VPN kann neu gestartet werden, um das Update sofort zu triggern.
• Endpunkte, die dieser Access Policy unterliegen, wird eine IPv4-Adresse der VPN-Netzwerkschnittstelle zugeordnet.
• Wenn eine DNS-Anfrage empfangen wird, die einer auf „Compatible" Modus eingestellten Access Policy entspricht, ist die AAAA-Antwort leer, aber eine A-Antwort wird mit einer IPv4-Cloud-Flow-Mapping statt einer IPv6 wie bei der Auswahl von „Optimized" zurückgegeben.
• Die IPv6-inkompatible / Legacy-App verwendet die in der A-Record-Antwort zurückgegebene IPv4-Adresse und stellt einen Socket auf diese Adresse her, der dank der veröffentlichten IPv4-Routen über Jamf ZTNA's VPN-Schnittstelle weitergeleitet wird.

Das Ergebnis ist eine nahezu identische Benutzererfahrung wie Optimized Routing, weniger einiger geringfügiger Ineffizienzen, die dem Einsatz von IPv6 versus IPv4 auf dem