Handleidingen

Doelgroep en doel

Dit document is bestemd voor netwerk- en beveiligings-IT-beheerders die ervaren zijn met de basisprincipes van netwerkwerking en VPN-technologieën.

Als volgende generatie beveiligings- en netwerkproduct gedraagt Jamf Connect ZTNA zich aanzienlijk anders dan een traditioneel VPN. Deze gids is bedoeld om beheerders te helpen de basisprincipes van het productontwerp te begrijpen om te helpen met planning, implementatie, onderhoud en probleemoplossing.

Deze gids is geen productdocumentatie waarin wordt beschreven hoe u Jamf's ZTNA-product kunt configureren, maar legt uit hoe het werkt zodat u het gedrag van het product in uw omgeving kunt voorspellen en begrijpen. Als u op zoek bent naar documentatie, vindt u deze in onze Jamf Connect ZTNA-documentatie, of als u eerst een technisch videooverzicht van het product wilt bekijken, bekijk dan de presentatie JNUC 2021 Jamf ZTNA Deep Dive.

We raden u ten zeerste aan deze gids te lezen (en op een bladwijzer te zetten!) als u Jamf Connect ZTNA in een productieomgeving binnen uw organisatie gebruikt.

Overzicht

Het ZTNA-product van Jamf is vanaf het begin ontworpen om te voldoen aan de architectuur van de Cloud Security Alliance (CSA) Software Defined Perimeter (SDP). Deze architectuur belichaamt veel van de principes van de bredere industriedefinitie van Zero Trust Network Access (ZTNA), inclusief Least Privileged Access, Role Based Access, Multi-factor Identity Verification, Device Trust en nog veel meer. Het product werd oorspronkelijk gebouwd door Wandera en overgenomen in het Jamf-beveiligingsplatform in juli 2021.

Hoewel Jamf Connect ZTNA veel van dezelfde resultaten deelt als een traditioneel VPN – zoals wanneer de VPN-interface online komt en externe bronnen beschikbaar worden – zijn de werkelijke mechanica om deze resultaten te ondersteunen volkomen anders. Dit is het gevolg van de manier waarop Connect ZTNA IP-adressering, DNS en cloudtechnologieën gebruikt om client-naar-server routing te leveren die een aanzienlijke stap voorwaarts is in termen van prestaties, schaalbaarheid en beveiliging in vergelijking met traditionele VPN-architecturen.

Dus laten we beginnen met een van de meest significante en belangrijke verschillen tussen de Jamf SDP en een traditioneel VPN: connection brokering versus routing.

Connection Brokering

Laten we hiermee beginnen: vergeet alles wat u weet en aanneemt over hoe een VPN werkt. Hoewel de uiteindelijke paketroutering uiteindelijk veel op een traditioneel VPN lijkt, is er een volledig nieuw verwerkingselement in het verbindingsproces.

Traditioneel VPN

Wanneer een apparaat verbinding maakt met een traditioneel VPN, wordt een beveiligde tunnel tot stand gebracht met een VPN-concentrator, die zich on-premises of in de cloud kan bevinden en door jezelf of een serviceprovider kan worden beheerd.

Ongeacht waar de concentrator is of wie deze bedient, is het algemene gedrag hetzelfde:

1. Het apparaat verifieert zich met de VPN-concentrator en een beveiligde tunnel wordt tot stand gebracht, waardoor een virtuele netwerkinterface op het eindpunt wordt gemaakt.
2. Aan het apparaat wordt dynamisch een IP-adres toegewezen door de concentrator dat geldig is voor de duur van die tunnel (soms kan het "statisch" worden gealloceerd door DHCP-binding).
3. Een of meer routes worden geconfigureerd voor de virtuele netwerkinterface, waarbij de netwerksubnetten van de organisatie worden gedefinieerd die via het VPN moeten worden gerouteerd. Een full tunnel VPN routeert al het verkeer van het apparaat naar de concentrator, waardoor alle lokale netwerktoegang wordt geëlimineerd.
4. Een DNS-naamserver wordt geconfigureerd op het apparaat, die meestal aan de andere kant van het VPN in het klantnetwerk zich bevindt.
5. Wanneer een app een verzoek aan een bron indient, wordt DNS omgezet in een IP-adres en wordt het verkeer via het VPN gerouteerd als het IP-adres van het pakket binnen een van de routes van de virtuele VPN-interface valt.
6. De VPN-concentrator routeert het pakket in het klantnetwerk. In sommige gevallen worden firewall-toegangscontrolelijsten in het netwerk geïmplementeerd om toegangsbeheer te beperken.

Hoewel dit zeker werkt, is het fundamentele beveiligingsprobleem met deze architectuur dat alle bronnen binnen de gerouteerde subnetten in wezen beschikbaar worden voor het apparaat. Dit stelt kwaadwillenden in staat verbinding te maken met IT-services en -servers waarmee de meeste eindpunten niet zouden moeten verbinden. Als u een kwaadwillende bent en het eindpunt kunt exploiteren, kunt u deze VPN-verbinding gebruiken om zwakke plekken op servers te vinden die "veilig" achter de firewall zijn en mogelijk niet volledig zijn gepatcht of anderszins correct zijn vergrendeld.

U kunt zeker toegangscontroleregels in het netwerk implementeren, maar dat is lastig en foutgevoelig. Meestal moeten dergelijke regels op het IP-adresvlak worden beheerd, dus ze zijn gevoelig voor fouten en gevaarlijk om te wijzigen. Dit resulteert in netwerkbeveiligingsbeleidsregels die snel worden ingehaald door het vereiste tempo van verandering voor nieuwe en evolerende toepassingen die van cruciaal belang zijn voor het netwerk. U heeft ook geen erg goede manier om monitoring en controlerapportage op een manier uit te voeren die de identiteit van een gebruiker sterk koppelt aan hun verbindingen. Wat doen de meeste organisaties dus? Laat het open en voeg de rapportage samen wanneer er een incident plaatsvindt.

Hoe lost u deze uitdagingen dan op? Welkom bij SDP en "brokered" netwerkverbindingen.

SDP: Connection Brokering

Wanneer Jamf's ZTNA verbonden is op een eindpuntapparaat, zijn er direct enkele significante verschillen:

1. Een stateless WireGuard-netwerkinterface wordt gemaakt op het eindpunt na een zeer lichte initiële handshake. N.b. afhankelijk van uw ZTNA-implementatie kunnen Apple-apparaten HTTP/3 gebruiken in plaats van WireGuard.
2. Een eenvoudige set van IPv6-routes – onderhandeld buiten het tot stand brengen van de interface – worden geconfigureerd voor de VPN-netwerkinterface. Deze routes behoren standaard niet tot de klant, maar zijn gereserveerde IPv6-bereiken die door Jamf worden beheerd (fd53:1c5a::/32, fddd:dddd::/128). De VPN-netwerkinterface krijgt ook een statisch IPv6-adres dat ook buiten de interface-onderhandeling is onderhandeld. Er worden standaard geen IPv4-adressen of routes aan de VPN-netwerkinterface toegewezen!
3. Een door Jamf beheerde DNS-naamserver fddd:dddd:: wordt geconfigureerd op het apparaat.

Wow. Wat? Ja, u leest dat goed: geen enterprise-zijde IP-adressen, subnetten of DNS-naamservers worden naar de routeringstabel van het eindpuntapparaat van de eindgebruiker gepubliceerd. Niet eens geen IPv4-adressen! Dit is een belangrijk bouwsteen van SDP connection brokering zodat het eindpunt en de gebruiker geen kennis hebben van de interne netwerktopologie en zelfs niet kunnen verbinden met interne netwerk-IP's als ze het probeerden.

Hoe maakt een toepassing op het apparaat dan verbinding met een app op een server die op een van die interne IPv4-subnetten leeft? Dat is waar connection brokering binnenkomt, gefaciliteerd door de magie van DNS, NAT en Jamf-routeringstechnologieën.

Info: Opmerking over Direct IP en Subnet Access

Naast de beveiligingsvoordelen van het niet publiceren van interne subnetten naar eindpunten – laat staan enig IPv4-adres – helpt het ook netwerksegoverlaps te voorkomen die gebruikers kunnen ervaren op niet-bedrijfsgebonden netwerken (bijv. thuis, koffieshop, enzovoort). Dit is van cruciaal belang om naadloos werken overal ter wereld mogelijk te maken.

Er zijn echter enkele specifieke use cases waarbij een IPv4-adres of subnet rechtstreeks bruikbaar moet zijn en niet kan vertrouwen op DNS-gebaseerde connection brokering. Voor die situaties ondersteunt Connect ZTNA het configureren van "Direct IP"-toegang. Raadpleeg de sectie "Brokered Connections Exceptions" van deze gids voor details.

Stel dat de gebruiker probeert verbinding te maken met App, die zich bij app.acmeinc.com bevindt en een intern IP-adres van 10.0.1.22 heeft. Dit is wat er gebeurt om die verbinding van een Jamf ZTNA-apparaat mogelijk te maken (het onderstaande voorbeeld toont een TCP-verbinding naar de doelapp, maar een soortgelijke flow wordt gebruikt voor UDP-verbindingen):

1. De gebruiker initieert een verbinding naar app.acmeinc.com vanuit hun browser naar keuze of een native app.
2. De app vraagt het besturingssysteem om die hostnaam om te zetten in een IP-adres om verbinding mee te maken. Met Jamf Connect ZTNA actief is de te gebruiken DNS-naamserver fddd:dddd::, wat een virtueel IPv6-adres is dat aan de Jamf Connect ZTNA-beleidsengine is gekoppeld.
3. Het besturingssysteem doet een reeks DNS-verzoeken naar fddd:dddd:: voor app.acmeinc.com, inclusief typen A, AAAA en HTTPS.
4. De Jamf Connect ZTNA DNS-naamserver voert een stroomopwaartse opzoeking van de FQDN uit, eerst kijkend of een Custom DNS Zone voor het domein is geconfigureerd (in dit voorbeeld *.acmeinc.com met 10.0.1.10 als de gezaghebbende naamserver). Als een Custom DNS Zone niet wordt gevonden, gebruikt de service een reeks openbare stroomopwaartse DNS-resolvers.
   1. Opmerking: De service vraagt alleen om een stroomopwaarts A-record aan; AAAA en HTTPS worden op dit moment genegeerd. Dit is alleen mogelijk een probleem voor servers die alleen bereikbaar zijn via IPv6, wat tegenwoordig uiterst zeldzaam is op de meeste openbare en particuliere netwerken.
5. Na ontvangst van de A DNS-antwoorden van een gezaghebbende server (in dit geval A 10.0.1.22 van de interne naamserver van de klant via een Custom DNS Zone-configuratie), identificeert de Jamf Connect ZTNA DNS-naamserver de gebruiker en het apparaat dat de bron aanvraagt en zoekt naar een overeenkomend Access Policy dat app.acmeinc.com als verkeerscriterium voor afstemming definieert.
   1. Dit toegangsbeleid evalueert het groepslidmaatschap van de gebruiker en de apparaatgezondheid om te bepalen of toegang tot de bron moet worden verleend.
   2. Ook in het beleid is gedefinieerd hoe verkeer via de Jamf-cloud moet worden gerouteerd. In dit geval gaan we ervan uit dat de klant een IPSec-onderlinge gateway heeft geconfigureerd als de particuliere route om deze interne app te bereiken.
6. Ervan uitgaande dat het toegangsbeleid wordt gevonden en het apparaat en de gebruiker alle criteria doorstaan die vereist zijn om verbinding met de bron tot stand te brengen, maakt de Jamf Connect ZTNA-routeringsfabric een "cloud flow mapping" die een kortstondige IPv6 in het gereserveerde IPv6-subnet toewijst dat aan het eindpunt is gepubliceerd (bijv. fd53:1c5a::aaaa:bbbb ↔ 10.0.1.22).
   1. Deze flow is uniek per verbinding en gebruiker, en kan niet worden hergebruikt buiten zijn levensduur of door enig ander apparaat.
7. Dit IPv6-adres fd53:1c5a::aaaa:bbbb wordt naar het eindpunt geretourneerd als het AAAA DNS-antwoord.
   1. De service retourneert standaard geen A of HTTPS-antwoord! Dit is erg belangrijk om in gedachten te houden bij het oplossen van DNS-antwoorden met hulpprogramma's als dig!
8. Een nieuwe socket naar fd53:1c5a::aaaa:bbbb wordt gemaakt, en omdat dat IP bestaat in het subnet dat aan de VPN-netwerkinterface van Jamf Connect ZTNA is toegewezen, wordt die socket en alle volgende pakketten via een WireGuard-tunnel naar de Jamf Security Cloud doorgestuurd.
9. Na ontvangst van het pakket voert de Jamf Connect ZTNA-routeringsfabric aanvullende beveiligingscontroles uit, lokaliseer dan de cloud flow mapping voor het IPv6-doeladres.
10. De Jamf Connect ZTNA-routeringsfabric routeert de pakketten over onze mondiale cloud-backbone, met als uiteindelijk doel de IPSec-onderling verbinding zoals gedefinieerd door het toegangsbeleid. Voordat het pakket via de IPSec-tunnel wordt doorgestuurd, treedt een NAT64-vertaling op volgens de cloud flow mapping, resulterend in een pakket met het oorspronkelijke IPv4-adres (10.0.1.22) als doel-IP.
    1. Het bron-IP van het pakket wordt ingesteld op een IP-adres in het subnet dat is gedefinieerd door de "Jamf Security Cloud Side" in de IPSec-configuratie. Al het verkeer dat naar het klantnetwerk wordt verzonden, lijkt afkomstig van een pseudo-willekeurig IP in dit subnet.
    2. Als u een regionaal datacenter voor cloud-gebaseerde NAT-egress gebruikt, wordt het bron-IP dynamisch verdeeld over de globale IP-adressen van dat datacenter.
11. Alle gematchte brokered verbindingen worden vastgelegd tegen de gebruiker, het apparaat en de toepassing, en kunnen worden bekeken in het Access Event Log in RADAR, onder andere rapporten.

Zoals u kunt zien, is er een nauwe koppeling van DNS, IP-routering en NAT die niet natief bestaat in traditionele VPN-configuraties.

Ondanks deze verschillen verwerkt Jamf Connect ZTNA pakketten uiterst efficiënt, omdat alle routering natiief op laag 3 plaatsvindt, gemakkelijk real-time toepassingen zoals VoIP en video ondersteunend. Omdat alle encapsulatie plaats vindt met behulp van het ultrasnel en efficiënte WireGuard- of HTTP/3 UDP-encapsulatie protocol, zijn er geen transmissieprotocol "meltdowns" die gebruikelijk zijn bij het routeren van TCP-verbindingen binnen een TCP/mTLS-gebaseerde tunnel op lossy netwerken.

Info: SDP, VPN en End-to-End App-encryptie

Jamf Connect ZTNA is ontwikkeld om snelle en dynamische software-gedefinieerde netwerkingmogelijkheden te bieden met behulp van moderne paketverpakkings- en versleutelingstechnologieën waarmee u verkeer van eindpunten naar vrijwel elke bestemming gemakkelijk kunt sturen en beleid kunt toepassen met een paar klikken in een webinterface.

Hoewel zoals elke VPN-technologie die verkeer versleutelt zodra het al in vlucht is, het voor Jamf onmogelijk is om echte end-to-end encryptie van gegevens van clienttoepassing naar servertoepassing te bieden.

Daarom moet u voor alle apps die gevoelige gegevens bevatten, ALTIJD dergelijke toepassingen configureren om app-niveau encryptietechnologieën zoals HTTPS of TLS te gebruiken. Dit is tegenwoordig standaardpraktijk voor alle toepassingen. Dit is de enige manier om ervoor te zorgen dat een ongeautoriseerde derde partij op geen enkel moment in het Jamf- of klantnetwerk toegang kan krijgen.

Deze connection brokering-techniek heeft zich op schaal op het Jamf ZTNA-platform op bedrijfsgraadprestaties bewezen. Alle moderne besturingssystemen ondersteunen IPv6 natiief (zelfs als het apparaat een IPv4-only netwerkverbinding heeft), en de grote meerderheid van toepassingen en gebruikers ondersteunen IPv6 en gebruiken DNS voor al hun verbindingen.

Dat is behalve voor degenen die dat niet doen... waarbij u speciale configuratie voor die uitschieters moet definiëren om te werken via Connect ZTNA.

Beschikbaarheid en failover

Jamf ZTNA is ontworpen met inachtheming van netwerkpartiëring en apparaten die geen verbinding kunnen maken met de Jamf Security Cloud. Dit gebeurt met behulp van verschillende overlappende methoden:-

Dead Gateway Detection

Jamf Trust kan gevaarlijke of instabiele verbindingen detecteren die vaak het gevolg zijn van onveilige captive portals. Deze captive portals kunnen verkeer onderscheppen wat verbindingsproblemen veroorzaakt.

Met dead gateway detection (DGD) kan de Jamf Trust-app meldingen geven op eindpuntapparaten over de huidige status van hun verbinding. DGD gebruikt algemene connectiviteitscontroles, zoals captive portal- en webconnectiviteitscontroles, terwijl deze Zero Trust Network Access (ZTNA) eindpuntresoluties gebruikt om een dead gateway te detecteren. Om DGD direct te ondersteunen, voorkomt bypass-modus in Jamf Trust dat gevaarlijk verkeer door de VPN-tunnel gaat. Dit stelt eindgebruikers in staat veilig op het internet te surfen zonder hun VPN- of werkgoederen.

Load-balanced en regionale ingresslocaties

Na het detecteren van een live verbinding vraagt Jamf Trust lokale IP-eindpunten aan die door de DNS-provider van het lokale netwerk zijn bepaald (meestal verstrekt door DHCP). De TTL (time-to-live) voor deze eindpunten is 60 seconden. Mocht een van deze eindpunten niet beschikbaar worden, dan worden zij binnen 60 seconden uit de pool verwijderd. Dit leidt tot een RTO (Recovery Time Objective) van tot 60 seconden, maar wanneer gecombineerd met Dead Gateway Detection, is het herstel van een enkel eindpuntfalen onmiddellijk.

Local policy caching

Zoals beschreven in SDP: Connection Brokering, gebruikt Jamf lokale DNS-vervangers om apparaatverkeer naar de juiste bron om te leiden. Deze lokale DNS-records hebben ook een TTL van 60 seconden. Mocht een beleidswijziging plaatsvinden (ofwel automatisch vanwege risicogebaseerd beleid, ofwel vanuit een administratieve wijziging), de langste periode voordat beleidsupdate lokaal op het apparaat is 60 seconden. N.b. het beleid leeft niet lokaal op het apparaat, maar vanwege DNS-caching kan het voorkomen dat een beleidsupdate elke 60 seconden wordt gepusht.

Brokered Connections Exceptions

Hoewel de meeste apps en services natiief en zonder speciale overweging via de Jamf ZTNA-service werken, zijn er enkele specifieke use cases en klassen van toepassingen die connectiviteit vereisen die niet wordt ondersteund door de brokered connection-benadering.

Apps/services die geen DNS gebruiken

Zoals u hierboven hebt geleerd, als een app of gebruiker geen FQDN voor verbinding met een bron gebruikt, nou, dat gaat gewoon niet werken.

Dit komt omdat zonder een DNS-verzoek om de verbinding in gang te zetten, een brokered IPv6-adres nooit wordt uitgegeven. En omdat het IP-adres van de bestemming niet aan de routeringstabel van het apparaat is toegevoegd, gaat dat pakket gewoon naar het internet en komt nooit terug.

Ongewoon in het totaal, verbindingsscenario's die geen FQDN's/DNS bevatten, zijn gebruikelijk voor:

• IT-beheerders die rechtstreeks verbinding maken met netwerkuitrusting
• Ontwikkelaars die verbinding maken met nieuwe instanties van virtuele instanties die niet bij DNS zijn geregistreerd
• Verouderde toepassingen die verbinding maken via een IPv4-adres, niet FQDN

Daarom ondersteunt Jamf Connect ZTNA de optionele definitie van "Direct IPs and Subnets" in het Access Policy van een app.

Error: Beveiliging en Direct IP en Subnet Exceptions

We raden aan IP-gebaseerde toegang alleen voor de gebruikers en apps te configureren die absoluut op deze manier toegang tot bronnen moeten hebben. En als u het doet, zijn de subnetten die u definieert zo nauw mogelijk scoped (bijv. 10.0.1.0/29) vs. (10.0.0.0/16).

Dit komt omdat door routering op zo'n breed niveau in te stellen, u in feite veel van de beveiligingsvoordelen van een brokering-connectiviteitsmodel ontkent, en teruggaat naar het gedrag van een traditioneel VPN. Dit laat uw organisatie kwetsbaar voor dezelfde soorten aanvallen die traditionele VPN's treffen, veroorzaakt door buitensporige toegang tot netwerkbronnen in te schakelen.

Wanneer u op deze manier een of meer IP-adressen configureert, worden de gedefinieerde CIDR-subnetten naar de routeringstabel van apparaten die aan dat beleid zijn toegewezen, gepubliceerd. Dit betekent dat naast het standaard fd53 IPv6-subnet, de VPN-netwerkinterface ook alle IPv4-subnetten bevat die in alle toepasselijke toegangsbeleidsregels zijn gedefinieerd.

Na het opslaan van een toegangsbeleid met deze IP-adressen gedefinieerd, kan het tot 30 minuten duren voordat deze wijzigingen naar alle apparaten worden doorgegeven. Het inschakelen en uitschakelen van Jamf Connect ZTNA activeert onmiddellijk een update van deze beleidsregels.

Nu, ervan uitgaande dat een 10.0.1.22 werd toegevoegd aan dezelfde App access policy, zou een Jamf ZTNA-eindgebruiker verbinding kunnen maken via http://10.0.1.22 of ping 10.0.1.22.

Het is vermeldenswaard dat, hoewel de verbinding niet via DNS is brokerd, de mogelijkheid om verbinding met de bron tot stand te brengen, nog steeds onderhevig is aan alle voorwaarden die in het Access Policy zijn gedefinieerd.

Apps die FQDN gebruiken, maar geen IPv6 ondersteunen

Er is een subset van toepassingen die om welke reden dan ook gewoon niet van IPv6 houden:

• Sommige moderne toepassingen hebben complexe/aangepaste netwerkstacks die eenvoudig niet compatibel zijn met IPv6 (bijv. Docker voor macOS)
• Verouderde toepassingen die geen idee hebben dat IPv6 bestaat en geen AAAA-antwoord kunnen gebruiken en mislukken wanneer er geen A-antwoord is.

Voor deze toepassingen kunt u een toegangsbeleid configureren om "Compatible" routering in plaats van "Optimized" te gebruiken. Als u dat doet, leidt dit tot het volgende:

• Eindpunten die onderhevig zijn aan het toegangsbeleid, krijgen een Jamf Cloud-uniek IPv4-subnet dat identiek werkt als het IPv6-bereik voor connection brokering
  • Dit zelfde bereik wordt gebruikt voor een of meer toegangsbeleidsregels die op deze manier zijn geconfigureerd.
  • Het kan tot 10 minuten duren voordat deze nieuwe route naar alle apparaten wordt gepubliceerd, of het VPN kan opnieuw worden opgestart om de update onmiddellijk te activeren.
• Eindpunten die onderhevig zijn aan het toegangsbeleid, krijgen een IPv4-adres op de VPN-netwerkinterface.
• Wanneer een DNS-verzoek wordt ontvangen dat overeenkomt met een Access Policy ingesteld op "Compatible" modus, is het AAAA-antwoord leeg, maar wordt er een A-antwoord geretourneerd met een IPv4 cloud flow mapping in plaats van een IPv6 als wordt gebruikt wanneer "Optimized" is geselecteerd.
• De IPv6-incompatibele / verouderde app gebruikt het IPv4-adres dat in het A-record antwoord is geretourneerd, en brengt een socket tot die adres die via de VPN-interface van Jamf ZTNA wordt gerouteerd dankzij de gepubliceerde IPv4-routes.

Het resultaat is een vrijwel identieke gebruikerservaring als Optimized routing, minus enkele kleine efficiënties die inherent zijn aan het gebruik van IPv6 versus IPv4 op de netwerkstack.

Dynamic Split Tunneling

Voor alle verbindingen die niet overeenkomen met een toegangsbeleid – via een brokered DNS-verbinding of direct IP – wordt het A/AAAA/HTTPS DNS-antwoord exact geretourneerd zoals geretourneerd door de stroomopwaartse DNS-resolver. Met andere woorden, het resultaat zou gelijk zijn aan het proberen verbinding te maken met de toepassing alsof Jamf ZTNA op het apparaat was uitgeschakeld.

In dit geval wordt geen cloud flow mapping voor deze verzoeken gemaakt, noch wordt er logging uitgevoerd (de uitzondering hierop is als u ook Jamf's Content Filtering en/of Web Threat Protection hebt geconfigureerd waarbij de verzoeken kunnen worden vastgelegd of geblokkeerd op basis van Internet of Security beleidsregels).

Dit resulteert in "dynamisch" split tunnel gedrag omdat in tegenstelling tot een traditionele split tunnel die is gebouwd met behulp van statische CIDR-bereiken, het verkeer dat door de tunnel wordt ingekapseld (of niet) in realtime kan worden gewijzigd. Dit wordt bereikt dankzij de brokered connection-methode zoals hierboven beschreven, waarbij een cloud flow mapping wordt geretourneerd, of het openbare DNS-antwoord wordt gebruikt, volledig op basis van actieve configuratie en de onmiddellijke context van het apparaat.

Local Networking

Goed nieuws! Tenzij u Direct IPs/Subnets hebt toegevoegd die overlappen met het subnet van het lokale netwerk van een gebruiker, werkt de meeste lokale netwerkconnectiviteit voor het apparaat prima! Dit is belangrijk voor lokale apparaten zoals printers, maar vooral voor mobiele apparaten waar veel gebruikers verwachten naadloos hun smart home of entertainment-georiënteerde apps te kunnen gebruiken wanneer zij zich in hun thuisnetwerk bevinden.

De meeste lokale netwerken hebben geen gezaghebbende DNS-zone, dus apparaten vertrouwen in plaats daarvan op mDNS om andere lokale apparaten te ontdekken en mee te verbinden. mDNS wordt niet beïnvloed wanneer de Jamf ZTNA DNS-server is ingesteld op de VPN-netwerkinterface, waardoor dit gedrag normaal blijft functioneren.

Wildcard / Not-Quite-ZTNA Access Policies

Hoewel de beveiligingsbeloften van ZTNA aantrekkelijk zijn, zal het overstappen van een open traditionele VPN-implementatie naar een granulaire, app-niveau ZTNA-omgeving enige tijd in beslag nemen. Het is onrealistisch voor de meeste organisaties om zonder een ongelooflijke hoeveelheid voorbereidingstesting en/of eindgebruikerslast van een ZTNA-gebaseerde VPN (zoals die van Jamf) over te stappen.

Daarom heeft Jamf Connect ZTNA zich aan deze realiteit aangepast zodat het op verschillende belangrijke manieren veel op een traditioneel VPN kan functioneren.

FQDN Wildcards

De meest granulaire en beste beveiligingsconfiguratie is om zoveel Access Policies als u apps hebt te configureren, met de specifieke FQDN's en hostnamen die voor elk worden gebruikt. Bijvoorbeeld, voor de toepassing App kunt u app.acmeinc.com en images.app.acmeinc.com hebben.

Echter, het eenvoudig ontdekken van al deze hostnamen, laat staan ze in een Access Policy configureren, kan aanzienlijk veel tijd in beslag nemen.

Daarom raden we, vooral als u proefdraaien of net begint met Jamf Connect ZTNA, aan om een Access Policy te maken met een naam zoals "Acme Inc Wildcard Default" en een hostnaam zoals *.acmeinc.com in te configureren. Deze ene regel zal alle verzoeken naar elke FQDN die acmeinc.com als domein gebruikt, "opvangen".

Dit is een geweldige manier om uw testinfrastructuur aan de gang te krijgen zodat u verkeer naar uw interne toepassingen kunt laten vloeien (ervan uitgaande dat u de juiste Custom DNS Zones en Interconnect Gateways heeft geconfigureerd natuurlijk).

Echter, u zult Access Policies willen maken voor uw bijzonder gevoelige toepassingen, of andere toepassingen die u ontdekt wanneer u naar de FQDN kijkt die wordt gebruikt voor de verbindingen die in de Access Event Logs worden gerapporteerd.

Om dit te vergemakkelijken, kunt u in Jamf Security Cloud access policies maken die hostnamen hebben die "within" de wildcard die in een ander Access Policy is gedefinieerd, vallen. Bijvoorbeeld, als u ontdekt dat app.acmeinc.com en images.app.acmeinc.com belangrijke toepassingen zijn waarvoor u specifieke Access Policies wilt maken, kunt u dat doen zonder de wildcard aan te passen. Na het maken van een nieuw Access Policy met die beter gedefinieerde FQDN's, zullen verkeersstromen beginnen met dat nieuwe App access policy overeen te stemmen, en niet met het wildcard-beleid.

Eenvoudig gezegd, de Connect ZTNA wildcard mapping regel stelt eerst de meest granulaire gedefinieerde hostnaam samen. Ervan uitgaande dat u twee geneste wildcard-beleidsregels hebt, zou images.app.acmeinc.com vóór *.acmeinc.com overeenkomen met .app.acmeinc.com. Natuurlijk, als u een derde access policy met images.app.acmeinc.com definieert, zou dit alle wildcard-regels verslaan.

Large IP-based CIDR Subnets

Net als hostnamen, kunnen er enkele apps zijn die buiten Direct IP-adresverbindingen werken en die enige tijd in beslag kunnen nemen om te ontdekken.

Hoewel wij sterk raden af om brede netwerksegmenten te definiëren (bijv. 10.0.0.0/8) omdat dit aanvallers in staat kan stellen lateraal (binnen een datacenter) en verticaal (over uw datacenters) via de VPN-verbinding te bewegen, zal er vaak behoefte zijn om met een routeringsconfiguratie te beginnen die aansluit bij die van een traditioneel VPN om een naadloze technologieovergang te verzekeren.

Om uw blootstelling te helpen verminderen raden we aan:

• IP-gebaseerde toegang alleen voor de gebruikers of apps definiëren die dit absoluut moeten hebben
• De CIDR-subnetten zo dicht mogelijk bij /32-adressen houden
• Het toekennen van een breed IP-gebaseerd toegangsbeleid aan een smalle groep pilotgebruikers, vervolgens controlerende gebeurtenislogboeken om:
  • De IP-adressen te ontdekken die worden gebruikt en meer nauwe access policies voor die te maken
  • Evalueren of het mogelijk is voor die gebruikers/apps om in de korte of middellange termijn over te schakelen naar FQDN, waardoor u op lange termijn de noodzaak van IP-gebaseerde toegang voor die app kunt verwijderen.

Endpoint-to-Jamf Cloud Connectivity

De Jamf Trust-client, die wordt gebruikt om de gebruiker te verifiëren en beveiligde connectiviteit tussen het eindpunt en de juiste Jamf Security Cloud-tenant tot stand te brengen, is op andere manieren behoorlijk "dom" vanuit een netwerkperspectief.

Het overgrote deel van de verwerking gebeurt in de cloud, waarbij de agent verantwoordelijk is voor het afhandelen van verbindingsbeheer naar de Jamf-routeringsfabric en anderszins pakketten ingekapseld en uitgepakt tussen de netwerkstack van het apparaat en de WireGuard- of HTTP/3-tunnel.

Het netwerkdetail dat hier de moeite waard is om aan te geven, is om ervoor te zorgen dat u de vereisten voor Endpoint Agent Traffic hebt beoordeeld om ervoor te zorgen dat uw firewalls alle noodzakelijke verkeer tussen eindpunten en de Jamf Security Cloud bij gebruik van uw bedrijfs-LAN toestaan.

Jamf Cloud-to-Customer/Data Connectivity

Zodra het verkeer van een eindpunt de Jamf Cloud bereikt, is elk pakket onderhevig aan cryptografische validatie en de Access Policies die voor die tenant en apparaat zijn gedefinieerd. Elk toegangsbeleid definieert een "volgende hop" route om de toepassing die door het beleid is gedefinieerd te bereiken, wat kan zijn:

• Een particuliere onderling verbinding (bijv. een site-to-site IPSec-tunnel)
• Een internet NAT egress gateway (bijv. een set van IP's met load balanced uit een datacenter naar keuze, of automatisch geselecteerd op basis van de locatie van de gebruiker)
• Direct van het apparaat zelf met behulp van openbare routes, en niet routing via de Jamf Security Cloud

Het is belangrijk om aan te geven dat al de bovenstaande volgende hop-routes alleen zijn toegestaan voor een apparaat als dat apparaat bevoegd is om de bron per het gedefinieerde Access Policy te bereiken. Als het apparaat niet bevoegd is om de bron per beleid te bereiken, dan:

• De verbinding wordt actief geblokkeerd/blackholed in het geval dat het risconiveau van het apparaat te hoog is
• De verbinding wordt behandeld alsof Jamf Connect ZTNA niet aanwezig is als het apparaat niet tot een groep behoort die is geautoriseerd voor toegang

Apparaten die bevoegd zijn om bronnen te bereiken zullen de route gebruiken die is gedefinieerd door het Access Policy. Hoewel deze route in het algemeen "gedeeld" is onder vele apparaten de eindbestemming, staat de Jamf ZTNA-beleidsengine alleen expliciet geautoriseerde apparaten, gebruikers en verbindingen in conforme contexten toe die routes op een gemaakte manier te gebruiken. Anderszins zijn die routes volledig onzichtbaar en onbeschikbaar voor use door eindpunten dankzij de fundamentele aard van de routeringsfabric.

Server/Infrastructure-to-Client Connections

Bij traditionele VPN's is het technisch mogelijk om verbinding te maken met services die luisteren op hun door VPN toegewezen IP-adressen. Dit werd traditioneel gebruikt voor extern bureaublad/ondersteuningsfuncties en andere verouderde toepassingen.

Echter, dit toegangsmodel wordt niet langer beschouwd als best practice. Dit is omdat het inschakelen van toepassingsservices op eindpunten aanzienlijke risico's met zich meebrengt vanwege kwetsbare software, misconfigurations en patchbeheerproblemen. Deze risico's kunnen een aanvaller in staat stellen toegang tot het eindpunt te krijgen, uiteindelijk lokale gegevens te bereiken, evenals als gateway te dienen naar bedrijfsgegevens en -infrastructuur via de VPN-verbinding van het eindpunt.

In plaats daarvan zijn veel van deze hulpprogramma's gemoderniseerd om vergelijkbare "brokered connection" architectuur te gebruiken, zodat het eindpunt een socket naar de service maakt, en de service vervolgens de verbinding met de ander verbindende partij op aanvraag samen voegt. Dit stelt het eindpunt in staat om in wezen in een "outbound only" modus te werken, waardoor vrijwel alle ingebonden poorten en protocollen op het apparaat kunnen worden geblokkeerd.

Om deze redenen ondersteunt Jamf geen infrastructuur-naar-eindpunt verbindingen. Dit vermindert drastisch het aanvalsoppervlak van eindpunten terwijl het eindpunt nog steeds volledige toegang tot alle toepassingen heeft die de gebruiker productief nodig heeft.

Validating and Testing Connectivity

De onderstaande secties zijn ontworpen om u beter te helpen bij het testen, diagnosticeren en oplossen van problemen met Jamf Connect ZTNA-gegevensstromen.

Jamf Trust Application Logging

Zowel macOS als Windows-versies van de Jamf Trust-apps bevatten de mogelijkheid om loggegevens naar een lokaal archief op uw apparaat te exporteren. Dit bestand wordt ontdaan van alle geheimen, maar bevat nuttige informatie over de configuratiestatus van het apparaat, evenals buiten-band communicatielogboeken tussen de client en server voor probleemoplossingsdoeleinden.

Testing with Netcheck Connectivity

De NetCheck Connectivity-app voor iOS en macOS (universele app) is een nuttig hulpprogramma van derden dat is gebouwd om de status van de netwerkstack van het apparaat te diagnosticeren, terwijl het ook de mogelijkheid biedt om een specifiek eindpunt te onderzoeken om te testen of het via Jamf ZTNA of niet wordt gerouteerd.

Dit hulpprogramma is erg nuttig om problemen te valideren die door eindgebruikers worden gerapporteerd wanneer u anderszins geen hands-on op het apparaat kunt krijgen. Gebruikers kunnen eenvoudig de app uit de App Store voor beide platforms verkrijgen, de test openen (waardoor de test automatisch wordt gestart), en vervolgens de resultaten delen met behulp van het shareblad, dat de resultaten in een JSON-bestand verpakt.

Testing with ping

De meest gemaakte fout is dat nadat u alles correct in Jamf Security Cloud hebt geconfigureerd (zonder Direct IP-adressen te definiëren of IPv4-compatibele routering te selecteren), een tester het volgende bevel in hun opdrachtregelgereedschap naar keuze geeft:

ping app.acmeinc.com

Wat dan terugkomt met iets als:

ping: cannot resolve app.acmeinc.com: Unknown host

"Wat?! Het is helemaal verbroken!"

Het probleem hier is dat ping als hulpprogramma niet natiief IPv6-bewust is. Specifiek zal ping alleen een A-record query voor de ingevoerde FQDN uitgeven, die prompt mislukt. Dit is onwaarschijnlijk al ander apps en browsers die vertrouwen op het besturingssysteem om opzoekingen uit te voeren, die uit gelijktijdig A/AAAA/HTTPS DNS-verzoeken zullen sturen.

Daarom is de fix eenvoudig, gebruik ping6 om het gebruik van IPv6 af te dwingen:

#ping6 app.acmeinc.com
PING6(56=40+8+8 bytes) fddd:dddd:1000:0:0:444:555:2222 --> fd53:1c5a:1000:111:222:333
16 bytes from fd53:1c5a:1000:111:222:333, icmp_seq=0 hlim=58 time=31.824 ms
16 bytes from fd53:1c5a:1000:111:222:333, icmp_seq=1 hlim=58 time=29.947 ms

Zolang app.acmeinc.com kan reageren op ICMP ping-verzoeken, wordt het bovenstaande antwoord ontvangen. Opmerking: er is geen indicatie van het interne IP-adres van de server van 10.0.1.22.

Testing with dig/nslookup

Net als bij het testen met ping, standaard dig en nslookup naar A-record opzoekingen wanneer op de opdrachtlijn gebruikt:

# dig app.acmeinc.com           
    
; <<>> DiG 9.10.6 <<>> app.acmeinc.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30788
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...

Net als bij ping moet u expliciet aangeven dat u de hostnaam wilt opzoeken met behulp van AAAA-query's:

# dig AAAA app.acmeinc.com
; <<>> DiG 9.10.6 <<>> AAAA app.acmeinc.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58465
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;app.acmeinc.com.                IN        AAAA
    
;; ANSWER SECTION:
app.acmeinc.com.        60        IN        AAAA        fd53:1c5a:1000:111:222:333
...

En maar om het grappig te maken, nslookup heeft een ander opdrachtregelswitch en syntaxis (aaaa in kleine letters).

# nslookup -type=aaaa app.acmeinc.com
Server: fddd:dddd::
Address: fddd:dddd::#53
    
app.acmeinc.com has AAAA address fd53:1c5a:1000:111:222:333

Info: Leuk feit: Waarom hebben we ping en ping6 als afzonderlijke opdrachten?

Per de ping6 man pagina:

Het ping6-hulpprogramma is opzettelijk gescheiden van ping(8).

Er zijn veel discussies geweest over waarom we ping6 en ping(8) scheiden. Sommige mensen betoogden dat het handiger zou zijn om de ping-opdracht voor zowel IPv4 als IPv6 uniform te maken. Het volgende is een antwoord op het verzoek.

Vanuit een ontwikkelaarsperspectief: aangezien de onderliggende raw sockets API volkomen verschillend is tussen IPv4 en IPv6, zouden we uiteindelijk twee types codebase hebben. Er zouden eigenlijk minder voordelen zijn om de twee opdrachten in een enkele opdracht voor de ontwikkelaar samen te voegen.

Vanuit een operatorperspectief: in tegenstelling tot gewone netwerkingapplicaties zoals externe aanmeldinghulpprogramma's, zijn we meestal op de hoogte van adresfamilie bij het gebruik van netwerkbeheergereedschap.
We willen niet alleen weten dat het bereikbaar is voor de host, maar willen weten dat het bereikbaar is voor de host via een bepaald netwerkprotocol zoals IPv6. Dus zelfs als we een uniforme ping(8)-opdracht voor zowel IPv4 als IPv6 hadden, zouden we meestal een -6 of -4 optie (of iets dergelijks) typen om de bepaalde adresfamilie op te geven.
Dit betekent in wezen dat we twee verschillende opdrachten hebben.

Microsoft en de makers van nslookup dachten anders!

FAQ

V: Waarom kan ik niet verbinden met mijn app of gegevensbron?! Hier zijn enkele voorgestelde stappen om te volgen:

1. Zorg ervoor dat u de juiste versie van ping gebruikt als u op die manier test.
2. Gebruik Netcheck om problemen aan de clientzijde uit te sluiten
   1. Als Netcheck werkte, is er waarschijnlijk een DNS-cachingprobleem in het spel. Start uw browser/app opnieuw en/of geef het volgende macOS-bevel: sudo killall -HUP mDNSResponder;sudo killall mDNSResponderHelper;sudo dscacheutil -flushcache. Om cachingproblemen te verminderen, wordt aanbevolen Jamf Connect ZTNA ingeschakeld te houden.
3. In Jamf Security Cloud / RADAR, controleert u Toegang > Gebeurtenislogboeken op fouten of activiteiten.
   1. Als u vermeldingen in het Gebeurtenislogboek ziet, betekent dit dat DNS correct wordt omgezet en is er waarschijnlijk een routing- of netwerk-/firewall ACL-probleem met de bron- of doel-IP's.
   2. Als u geen vermeldingen ziet, controleert u of uitgaand Jamf-clientverkeersverkeer niet door uw netwerk per de Endpoint Agent Traffic-gids wordt geblokkeerd.
4. Als de doeltoepassing via een IPSec-tunnel bereikbaar moet zijn:
   1. Bevestig dat de tunnel "up" is volgens Jamf Security Cloud / RADAR en uw kant van de firewall-verbinding. Indien niet beschikbaar, kunnen deze gidsen nuttig zijn om uw configuratie te valideren.
   2. Bevestig dat u het test-IP-adres van de "Jamf-kant" dat in Jamf Security Cloud / RADAR voor de IPSec-verbinding is verstrekt, van het apparaat dat de tunnel aan uw kant beëindigt kunt pingen.
      1. Als dat werkt, maar u het zelfde IP van andere apparaten in uw netwerk niet kunt pingen, mist u waarschijnlijk interne routeringsconfiguraties. U moet ervoor zorgen dat de Jamf IP-subnet(en) naar het apparaat/apparaat dat uw kant van de tunnel afhandelt, worden gerouteerd.

Als u verder hulp nodig hebt, aarzel niet om contact op te nemen met Jamf-ondersteuning voor hulp.

V: Ik heb een apptoegangsaktueel beleid met specifieke groepen geconfigureerd die die app mogen gebruiken. Wat gebeurt er met het verkeer dat van een gebruiker/apparaat wordt ontvangen dat NIET in die groep zit? Het verkeer van niet-toegewezen apparaten wordt behandeld alsof het app-toegangsbeleid niet bestaat. Met andere woorden, een openbaar DNS-antwoord – als een bestaat – wordt naar het apparaat geretourneerd, niet een kortstondige IPv6-adres.

V: Ik heb Cisco Meraki WiFi-apparatuur en mijn Jamf ZTNA-verbindingen werken intermitterend niet meer. Wat is er mis? Meraki's "Layer 7 Statistical AI" blokkeeringsfunctie blokkeert ten onrechte en intermitterend Jamf's WireGuard-verkeer als P2P. Neem contact op met Meraki Support voor hulp bij het beheren van deze instelling als dit van invloed is op uw omgeving.