Guides

Odbiorcy i cel

Ten dokument jest przeznaczony dla administratorów IT zajmujących się siecią i bezpieczeństwem, posiadających doświadczenie z fundamentami sieci i technologii VPN.

Jako produkt bezpieczeństwa i sieci nowej generacji, Jamf Connect ZTNA zachowuje się znacznie inaczej niż tradycyjne VPN. Ten przewodnik ma pomóc administratorom zrozumieć podstawy projektu produktu, aby wspomóc planowanie, wdrażanie, konserwację i rozwiązywanie problemów.

Ten przewodnik nie jest dokumentacją produktu opisującą sposób konfiguracji produktu ZTNA Jamf, ale wyjaśnia, jak to działa, aby można było przewidywać i rozumieć zachowanie produktu w Twoim środowisku. Jeśli szukasz dokumentacji, możesz ją znaleźć w naszej dokumentacji Jamf Connect ZTNA, lub jeśli chcesz najpierw obejrzeć techniczny przegląd wideo produktu, obejrz prezentację JNUC 2021 Jamf ZTNA Deep Dive.

Zdecydowanie zalecamy przeczytanie (i zaznaczenie!) tego przewodnika, jeśli używasz Jamf Connect ZTNA w środowisku produkcyjnym w Twojej organizacji.

Przegląd

Produkt ZTNA Jamf został zaprojektowany od początku, aby zgodnie z Software Defined Perimeter (SDP) architecture Cloud Security Alliance. Ta architektura ucieleśnia wiele zasad szerszej definicji branżowej Zero Trust Network Access (ZTNA), w tym dostęp najmniej uprzywilejowany, dostęp oparty na rolach, weryfikacja tożsamości wieloskładnikowej, zaufanie do urządzenia i wiele innych. Produkt został pierwotnie zbudowany przez Wandera i przejęty do platformy bezpieczeństwa Jamf w lipcu 2021 roku.

Chociaż Jamf Connect ZTNA dzieli wiele tego samego z tradycyjnym VPN - takie jak gdy interfejs VPN przejdzie do trybu online, zasoby zdalne stają się dostępne - rzeczywista mechanika obsługi tych rezultatów jest całkowicie inna. Jest to wynikiem sposobu, w jaki Connect ZTNA wykorzystuje adresowanie IP, DNS i technologie chmurowe, aby dostarczać routing klient-serwer, który stanowi zmianę znacząca w zakresie wydajności, skalowalności i bezpieczeństwa w porównaniu z tradycyjnymi architekturami VPN.

Dlatego zaczyńmy od jednej z najistotniejszych i najważniejszych różnic między SDP Jamf a tradycyjnym VPN: obsługa połączeń versus routing.

Obsługa połączeń

Zacznijmy od tego: weź wszystko, co wiesz i zakładasz o tym, jak działa VPN, i na chwilę to odłóż. Chociaż ostateczny routing pakietów wygląda podobnie do tradycyjnego VPN, w procesie połączenia istnieje całkowicie nowy element przetwarzania.

Tradycyjne VPN

Gdy urządzenie łączy się z tradycyjnym VPN, tworzy bezpieczny tunel z koncentratorem VPN, który może znajdować się lokalnie lub w chmurze i być obsługiwany przez Ciebie lub dostawcę usług.

Niezależnie od tego, gdzie znajduje się koncentrator i kto go obsługuje, ogólne zachowanie jest takie samo:

1. Urządzenie uwierzytelnia się z koncentratorem VPN, a bezpieczny tunel jest nawiązywany, tworząc wirtualny interfejs sieciowy na punkcie końcowym.
2. Urządzeniu jest dynamicznie przydzielany adres IP przez koncentrator, który jest ważny przez okres trwania tego tunelu (czasami może być "statycznie" przydzielony przez powiązanie DHCP).
3. Jeden lub więcej tras jest konfigurowany dla wirtualnego interfejsu sieciowego, definiując podsieci sieciowe należące do organizacji, które powinny być kierowane przez VPN. Pełne tunelowe VPN kieruje cały ruch z urządzenia do koncentratora, eliminując cały dostęp do sieci lokalnej.
4. Serwer nazw DNS jest konfigurowany na urządzeniu, który zwykle znajduje się po drugiej stronie VPN w sieci klienta.
5. Whenever an app makes a request to a resource, DNS is resolved to an IP address and the traffic is routed via the VPN if the IP address of the packet falls within one of the routes of the VPN virtual interface.
6. Koncentrator VPN kieruje pakiet do sieci klienta. W niektórych przypadkach listy kontroli dostępu zapory sieciowej są wdrażane w całej sieci, aby ograniczyć kontrolę dostępu.

Chociaż to na pewno działa, główny problem bezpieczeństwa tej architektury polega na tym, że wszystkie zasoby w ramach kierowanych podsieci są zasadniczo dostępne dla urządzenia. To pozwala na łączność z usługami IT i serwerami, z którymi większość punktów końcowych nie powinna się łączyć. Jeśli jesteś sprawcą i uda Ci się eksploatować punkt końcowy, możesz użyć tego połączenia VPN, aby znaleźć słabe punkty na serwerach, które są "bezpieczne" za zaporą sieciową i mogą nie być w pełni zainstalowane lub w inny sposób zablokowane.

Oczywiście możesz wdrożyć reguły kontroli dostępu w sieci, ale to trudne i podatne na błędy. Zwykle takie reguły muszą być zarządzane na warstwie adresu IP, dlatego mają tendencję do bycia kruche i niebezpieczne w zmianach. Powoduje to politykę bezpieczeństwa na poziomie sieci, która szybko wyprzedza wymaganą szybkość zmian dla nowych i rozwijających się aplikacji, które są krytyczne dla misji w sieci. Również nie masz zbyt wspaniałego sposobu na monitorowanie i audytowanie raportowania w sposób, który ściśle łączy tożsamość użytkownika z jego połączeniami. Czego zatem robią większość organizacji? Zostawiają to otwarte i łączą raportowanie razem w razie incydentu.

Jak naprawić te wyzwania? Wejdź SDP i "obsługiwane" połączenia sieciowe.

SDP: Obsługa połączeń

Gdy Jamf's ZTNA jest podłączony na urządzeniu punktu końcowego, istnieją znaczące różnice od samego początku:

1. Bezstanowy interfejs sieciowy Wireguard jest tworzony na punkcie końcowym po bardzo lekkim początkowym uściskiem dłoni. N.b. w zależności od wdrażania ZTNA, urządzenia Apple mogą używać HTTP/3 zamiast Wireguard.
2. Prosty zestaw tras IPv6 – negocjowanych poza pasmem ustanowienia interfejsu – są konfigurowane dla interfejsu sieciowego VPN. Domyślnie, te trasy nie należą do klienta, ale są zarezerwowanymi zakresami IPv6 zarządzanymi przez Jamf (fd53:1c5a::/32, fddd:dddd::/128). Interfejsowi sieciowemu VPN przydzielany jest również statyczny adres IPv6, który został również wynegocjowany poza pasmem. Domyślnie brak adresów IPv4 ani tras przydzielonych interfejsowi sieciowemu VPN!
3. Serwer nazw DNS zarządzany przez Jamf fddd:dddd:: jest konfigurowany na urządzeniu.

Wow. Co? Tak, czytasz dobrze: brak adresów IP, podsieci lub serwerów nazw DNS po stronie przedsiębiorstwa opublikowanych w tabeli tras urządzenia użytkownika końcowego. Nawet żadnych adresów IPv4! To jest kluczowy blok budowlany brokera obsługi SDP, tak aby punkt końcowy i użytkownik nie mieli świadomości wewnętrznej topologii sieci i nie mogą się połączyć z wewnętrznymi adresami IP, nawet jeśli by spróbowali.

Jak zatem aplikacja na urządzeniu łączy się z aplikacją na serwerze, która znajduje się w jednej z tych wewnętrznych podsieci IPv4? To tutaj wchodzi obsługa połączeń, ułatwiana przez magię DNS, NAT i technologii routingu Jamf.

Info: Notatka o dostępie bezpośrednim IP i podsieci

Oprócz korzyści bezpieczeństwa związanych z nieudostępnianiem wewnętrznych podsieci do punktów końcowych – co więcej, żadnych adresów IPv4 – pomaga to również w unikaniu nakładania się segmentów sieci, które użytkownicy mogą doświadczać w niezarządzanych przez firmę sieciach (np. dom, kawiarnia itp.). To jest krytyczne umożliwienie bezproblemowej pracy z dowolnego miejsca.

Jednak istnieją specjalne przypadki użycia, w których adres IPv4 lub podsieć muszą być bezpośrednio użyteczne i nie mogą polegać na obsłudze połączeń opartej na DNS. W takich sytuacjach Connect ZTNA obsługuje konfigurowanie dostępu "Bezpośredni IP". Więcej szczegółów znajduje się w sekcji "Wyjątki obsługiwanych połączeń" tego przewodnika.

Załóżmy, że użytkownik próbuje nawiązać połączenie z App, która znajduje się w app.acmeinc.com i ma wewnętrzny adres IP 10.0.1.22. Oto co się dzieje, aby ułatwić to połączenie z urządzenia obsługiwanego przez Jamf ZTNA (poniższy przykład pokazuje połączenie TCP do aplikacji docelowej, ale podobny przepływ jest używany dla połączeń UDP):

1. Użytkownik inicjuje połączenie z app.acmeinc.com z przeglądarki lub natywnej aplikacji.
2. Aplikacja prosi system operacyjny o rozwiązanie tej nazwy hosta, aby uzyskać adres IP do nawiązania połączenia. Z aktywnym Jamf Connect ZTNA, serwerem nazw DNS do użycia jest fddd:dddd::, czyli wirtualny adres IPv6, który jest powiązany z silnikiem polityki Jamf Connect ZTNA.
3. System operacyjny wysyła serię żądań DNS do fddd:dddd:: dla app.acmeinc.com, w tym typów A, AAAA i HTTPS.
4. Serwer nazw DNS Jamf Connect ZTNA wykonuje wyszukiwanie nadrzędne FQDN, najpierw sprawdzając, czy Custom DNS Zone został skonfigurowany dla domeny (*.acmeinc.com z 10.0.1.10 jako autorytatywnym serwerem nazw w tym przykładzie). Jeśli strefa DNS niestandardowa nie zostanie znaleziona, usługa korzysta z serii publicznych rezolwerów DNS nadrzędnych.
   1. Notatka: Usługa żąda tylko rekordu A nadrzędnego, podczas gdy AAAA i HTTPS są ignorowane w tej chwili. To jest tylko potencjalny problem dla serwerów, które są tylko dostępne przez IPv6, co jest niezwykle rzadkie dzisiaj w większości sieci publicznych i prywatnych.
5. Po otrzymaniu odpowiedzi DNS A od autorytatywnego serwera (w tym przypadku A 10.0.1.22 z wewnętrznego serwera nazw klienta za pośrednictwem konfiguracji strefy DNS niestandardowej), serwer nazw DNS Jamf Connect ZTNA identyfikuje użytkownika i urządzenie żądające zasobu i szuka pasującą Access Policy, która definiuje app.acmeinc.com jako kryterium dopasowania ruchu.
   1. Ta polityka dostępu ocenia członkostwo grupy użytkownika i stan zdrowia urządzenia, aby ustalić, czy dostęp do zasobu powinien zostać przyznany.
   2. Również zdefiniowana w polityce to sposób, w jaki ruch powinien być kierowany przez chmurę Jamf. W tym przypadku założymy, że klient skonfigurował bramę połączenia IPSec, aby służyć jako prywatna trasa dostępu do tej wewnętrznej aplikacji.
6. Zakładając, że polityka dostępu zostanie znaleziona i urządzenie oraz użytkownik przejdą wszystkie kryteria wymagane do nawiązania połączenia z zasobem, sieć routingu Jamf Connect ZTNA tworzy "mapowanie przepływu chmury", które przypisuje efemeryczny IPv6 w zarezerwowanej podsieci IPv6 opublikowanej do punktu końcowego (np. fd53:1c5a::aaaa:bbbb ↔ 10.0.1.22).
   1. Ten przepływ jest unikalny na połączenie i użytkownika i nie może być ponownie używany poza jego okresem istnienia lub przez żadne inne urządzenie.
7. Ten adres IPv6 fd53:1c5a::aaaa:bbbb jest zwracany do punktu końcowego jako odpowiedź DNS AAAA.
   1. Usługa nie zwraca odpowiedzi A ani HTTPS domyślnie! Jest to bardzo ważne, aby pamiętać podczas rozwiązywania problemów z odpowiedziami DNS przy użyciu narzędzi takich jak dig!
8. Nowe gniazdo do fd53:1c5a::aaaa:bbbb jest tworzone, a ponieważ ten adres IP istnieje w podsieci przydzielonej do interfejsu sieciowego VPN Jamf Connect ZTNA, to gniazdo i wszystkie kolejne pakiety są przekazywane tam i z powrotem za pośrednictwem tunelu Wireguard do chmury bezpieczeństwa Jamf.
9. Po otrzymaniu pakietu sieć routingu Jamf Connect ZTNA wykonuje dodatkowe sprawdzenia bezpieczeństwa, a następnie lokalizuje mapowanie przepływu chmury dla docelowego adresu IPv6.
10. Sieć routingu Jamf Connect ZTNA kieruje pakiety na całym globalnym szkielecie chmury Jamf, ostatecznie osiągając połączenie IPSec zdefiniowane przez politykę dostępu. Przed przesłaniem pakietu przez tunel IPSec następuje translacja NAT64 zgodnie z mapowaniem przepływu chmury, co powoduje pakiet z oryginalnym adresem IPv4 (10.0.1.22) jako docelowym adresem IP.
    1. Źródłowy adres IP pakietu jest ustawiony na adres IP w podsieci zdefiniowanej przez "Jamf Security Cloud Side" w konfiguracji IPSec. Cały ruch wysyłany do sieci klienta będzie pochodzić z pseudo-losowego IP w tej podsieci.
    2. Jeśli używasz regionalnego centrum danych dla NAT egress opartego na chmurze, źródłowy adres IP będzie dynamicznie rozkładany między globalne adresy IP tego centrum danych.
11. Wszystkie dopasowane obsługiwane połączenia są rejestrowane względem użytkownika, urządzenia i aplikacji i są dostępne do przeglądu w dzienniku zdarzeń dostępu w RADAR, wśród innych raportów.

Jak widać, istnieje ścisłe sprzęganie DNS, routingu IP i NAT, które po prostu nie istnieje natywnie dla tradycyjnych konfiguracji VPN.

Chociaż pomimo tych różnic, Jamf Connect ZTNA obsługuje pakiety niezwykle wydajnie, ponieważ cały routing występuje natywnie na warstwie 3, z łatwością obsługując aplikacje w czasie rzeczywistym, takie jak VoIP i wideo. Ponieważ cała enkapsulacja odbywa się przy użyciu szybkiego i wydajnego protokołu enkapsulacji Wireguard lub HTTP/3 UDP, nie ma "zawalenia" protokołu transmisji, które są powszechne przy kierowaniu połączeń TCP w tunelu opartym na TCP/mTLS w sieciach stratnych.

Info: SDP, VPN i szyfrowanie end-to-end aplikacji

Jamf Connect ZTNA został opracowany w celu zapewnienia szybkich i dynamicznych możliwości sieci definiowanej programowo przy użyciu nowoczesnych technologii enkapsulacji i szyfrowania pakietów, aby umożliwić Ci łatwe sterowanie i stosowanie polityki do ruchu z punktów końcowych do praktycznie każdego celu za pomocą kilku kliknięć w interfejsie sieciowym.

Chociaż podobnie jak każda technologia VPN, która szyfruje ruch, gdy jest już w tranzycie, jest niemożliwe dla Jamf, aby zapewnić prawdziwe szyfrowanie end-to-end danych z aplikacji klienta do aplikacji serwera.

Dlatego dla każdych aplikacji, które zawierają jakiś poziom poufnych danych, zawsze musisz skonfigurować takie aplikacje, aby używały technologii szyfrowania na poziomie aplikacji, takich jak HTTPS lub TLS. Jest to teraz standardowa praktyka dla wszystkich aplikacji. Jest to jedyna droga, aby zapewnić, że nieautoryzowany pośrednik nie będzie w stanie uzyskać dostępu w żadnym punkcie na całej sieci Jamf lub klienta.

Ta technika brokera obsługi okazała się działać w wydajności i skali poziomu przedsiębiorstwa na platformie Jamf ZTNA. Wszystkie nowoczesne systemy operacyjne natywnie obsługują IPv6 (nawet jeśli urządzenie ma połączenie sieciowe tylko IPv4), a zdecydowana większość aplikacji i użytkowników obsługuje IPv6 i używa DNS do wszystkich swoich połączeń.

To z wyjątkiem tych, które nie ... w związku z czym będziesz potrzebować zdefiniować specjalną konfigurację dla tych przypadków odtwórzenia do pracy poprzez Connect ZTNA.

Dostępność i tryb failover

Jamf ZTNA jest zaprojektowany z uwzględnieniem partycjonowania sieci i urządzeń niezbędnych do nawiązania połączenia z chmurą bezpieczeństwa Jamf. Robi to za pomocą różnych nakładających się metod:-

Wykrywanie martwej bramy

Jamf Trust może wykryć niebezpieczne lub niestabilne połączenia, które często wynikają z niezabezpieczonych portali zniewolonych. Te portale plenipotencjarne mogą przechwytywać ruch, co powoduje problemy z łącznością.

Dzięki wykrywaniu martwej bramy (DGD) aplikacja Jamf Trust może wysyłać powiadomienia na urządzenia użytkowników końcowych dotyczące aktualnego stanu ich połączenia. DGD wykorzystuje ogólne sprawdzenia łączności, takie jak sprawdzenia portalu plenipotencjarnego i łączności sieci Web, podczas gdy wykorzystuje rozdzielczości punktu końcowego sieci zero trust (ZTNA) do wykrywania martwej bramy. Aby bezpośrednio obsługiwać DGD, tryb bypass w Jamf Trust zapobiega przechodzeniu niebezpiecznego ruchu przez tunel VPN. Dzięki temu użytkownicy końcowi mogą bezpiecznie przeglądać Internet bez sieci VPN ani aplikacji roboczych.

Lokalizacje przychodzenia zrównoważonego obciążenia i regionalne

Po wykryciu aktywnego połączenia, Jamf Trust żąda lokalnych punktów końcowych IP określonych z dostawcy DNS sieci lokalnej (zazwyczaj udostępniane przez DHCP). TTL (czas życia) dla tych punktów końcowych wynosi 60 sekund. Jeśli jeden z tych punktów końcowych stanie się niedostępny, zostanie usunięty z puli w ciągu 60 sekund. Prowadzi to do RTO (Recovery Time Objective) do 60 sekund, ale w połączeniu z wykrywaniem martwej bramy, odzyskiwanie z awarii pojedynczego punktu końcowego jest natychmiastowe.

Buforowanie polityki lokalnej

Jak opisano w SDP: Connection Brokering, Jamf wykorzystuje lokalne zastępniki DNS do kierowania ruchu urządzenia do odpowiedniego zasobu. Te lokalne rekordy DNS mają również TTL 60 sekund. Jeśli zmiana polityki zostanie uchwycona (automatycznie z powodu polityki ryzyka lub ze zmian administracyjnych), najdłuższy okres przed aktualizacją polityki lokalnie na urządzeniu wynosi 60 sekund. N.b. polityka nie znajduje się lokalnie na urządzeniu, ale ze względu na buforowanie DNS może się wydawać, że aktualizacja polityki jest push co 60 sekund.

Wyjątki obsługiwanych połączeń

Chociaż większość aplikacji i usług działa natywnie i bez specjalnych uwzględnień za pośrednictwem usługi Jamf ZTNA, istnieją szczególne przypadki użycia i klasy aplikacji, które wymagają łączności nieobsługiwanej przez podejście obsługiwanego połączenia.

Aplikacje/usługi, które nie używają DNS

Jak się dowiedziałeś powyżej, jeśli aplikacja lub użytkownik nie używa FQDN do nawiązania połączenia z zasobem, to po prostu nie zadziała.

Jest to dlatego, że bez żądania DNS, aby rozpocząć połączenie, obsługiwany adres IPv6 nigdy nie będzie wystawiony. A ponieważ adres IPv4 docelowego nie jest dodawany w tabeli tras urządzenia, ten pakiet po prostu trafi do Internetu i nigdy się nie wróci.

Chociaż niezwykła w agregacie, scenariusze łączności, które nie obejmują FQDN/DNS, są powszechne dla:

• Administratorów IT próbujących nawiązać połączenie z urządzeniami sieciowymi bezpośrednio
• Deweloperów łączących się z nowymi instancjami instancji wirtualnych, które nie są zarejestrowane w DNS
• Starszych aplikacji, które łączą się za pośrednictwem adresu IPv4, a nie FQDN

Z tego powodu Jamf Connect ZTNA obsługuje opcjonalną definicję "Direct IPs and Subnets" w Access Policy aplikacji.

Error: Bezpieczeństwo i wyjątki bezpośredniego IP i podsieci

Zalecamy tylko konfigurowanie dostępu opartego na IP dla użytkowników i aplikacji, które absolutnie muszą mieć dostęp do zasobów w ten sposób. A jeśli je skonfigurujesz, podsieci, które definiujesz, są ograniczone jak najwęże (np. 10.0.1.0/29) vs (10.0.0.0/16).

To dlatego, że poprzez ustanowienie routingu na takim szerokim poziomie, faktycznie negują wiele korzyści bezpieczeństwa modelu łączności brokera, powracając do zachowania tradycyjnego VPN. To pozostawia organizację podatną na te same rodzaje ataków, które wpływają na tradycyjne sieci VPN spowodowane włączeniem nadmiernego dostępu do zasobów sieciowych.

Podczas konfigurowania jednego lub więcej adresów IP w ten sposób, określone podsieci CIDR będą opublikowane w tabeli tras urządzeń przydzielonych do tej polityki. Oznacza to, że oprócz domyślnej podsieci fd53 IPv6, interfejs sieciowy VPN będzie zawierać również wszystkie podsieci IPv4 zdefiniowane we wszystkich mających zastosowanie politykach dostępu.

Po zapisaniu polityki dostępu z tymi zdefiniowanymi adresami IP, propagacja tych zmian do wszystkich urządzeń może trwać do 30 minut. Włączenie i wyłączenie Jamf Connect ZTNA wyzwoli natychmiastową aktualizację tych polityk.

Teraz, zakładając, że 10.0.1.22 został dodany do tej samej polityki dostępu App, użytkownik końcowy Jamf ZTNA byłby w stanie nawiązać połączenie przez http://10.0.1.22 lub ping 10.0.1.22.

Warto zauważyć, że chociaż połączenie nie jest obsługiwane przez DNS, możliwość nawiązania połączenia z zasobem jest nadal podlegać wszystkim warunkom zdefiniowanym w Polityce dostępu.

Aplikacje używające FQDN, ale nieobsługujące IPv6

Istnieje podzbiór aplikacji, które z wielu powodów po prostu nie lubią IPv6:

• Niektóre nowoczesne aplikacje mają złożone/niestandardowe stosy sieciowe, które po prostu nie są kompatybilne z IPv6 (np. Docker dla macOS)
• Starsze aplikacje, które nie mają pojęcia, że IPv6 istnieje, i są niezdolne do wykorzystania odpowiedzi AAAA i nie działają, gdy nie ma odpowiedzi A.

Dla tych aplikacji możesz skonfigurować politykę dostępu do używania routingu "Compatible" zamiast "Optimized". Zrobienie tego spowoduje następujące:

• Punkty końcowe podlegające polityce dostępu będą naciskane unikalnym podsieci IPv4 chmury Jamf, które działają identycznie w naturze do zakresu IPv6 dla brokera obsługi
  • Ten sam zakres jest używany dla jednej lub więcej polityk dostępu skonfigurowanych w ten sposób.
  • Propagacja tej nowej trasy do wszystkich urządzeń może trwać do 10 minut, lub sieć VPN może zostać ponownie uruchomiona, aby natychmiast wyzwolić aktualizację.
• Punkty końcowe podlegające polityce dostępu będą przydzielane adresem IPv4 w interfejsie sieciowym VPN.
• Gdy żądanie DNS jest odbierane, które odpowiada Access Policy ustawionej na "Compatible" tryb, odpowiedź AAAA będzie pusta, ale odpowiedź A będzie zwrócona przy użyciu mapowania przepływu chmury IPv4 zamiast IPv6, które jest używane po wybraniu "Optimized".
• Aplikacja niekompatybilna z IPv6 / starsze będzie używać adresu IP zwróconego w odpowiedzi A i ustanowić gniazdo do tego adresu, które będzie kierowane przez interfejs sieciowy Jamf ZTNA VPN dzięki opublikowanym trasom IPv4.

Rezultatem jest prawie identyczne doświadczenie użytkownika co Optimized routing, mniej pewnych drobnych wydajności nieodłącznych przy użyciu IPv6 vs IPv4 w stosie sieciowym.

Dynamiczny tunel podzielony

Dla wszystkich połączeń, które nie pasują do polityki dostępu - czy to poprzez obsługiwane połączenie DNS lub bezpośredni IP - odpowiedź A/AAAA/HTTPS DNS jest zwracana dokładnie tak, jak zwrócona przez zalesienie DNS nadrzędne. Innymi słowy, wynik byłby równoważny próbie nawiązania połączenia z aplikacją, tak jakby Jamf ZTNA był wyłączony na urządzeniu.

W tym przypadku żadne mapowanie przepływu chmury nie jest tworzone dla tych żądań, ani nie wykonywane rejestrowanie (wyjątek jest, jeśli również skonfigurowano filtrowanie zawartości Jamf i/lub ochronę zagrożeń sieciowych, gdzie żądania mogą być zarejestrowane lub zablokowane na podstawie Internet lub Security polityk).

Powoduje to zachowanie "dynamicznego" tunelu podzielonego, ponieważ w przeciwieństwie do tradycyjnego tunelu podzielonego zbudowanego przy użyciu statycznych zakresów CIDR, ruch enkapsulowany (lub nie) przez tunel może być zmieniany w czasie rzeczywistym. Jest to osiągane dzięki metodzie obsługiwanego połączenia, jak opisano powyżej, gdzie mapowanie przepływu chmury jest zwracane, lub publiczna odpowiedź DNS jest używana, całkowicie na podstawie aktywnej konfiguracji i natychmiastowego kontekstu urządzenia.

Sieci lokalne

Dobre wieści! Chyba że dodałeś bezpośrednie IP/podsieci, które nakładają się na podsieć sieci lokalnej użytkownika, większość lokalnej łączności sieciowej urządzenia działa świetnie! Jest to ważne dla urządzeń lokalnych, takich jak drukarki, ale szczególnie ważne dla urządzeń mobilnych, gdzie wielu użytkowników oczekuje, że będzie mogło bezproblemowo korzystać z inteligentnych domów lub aplikacji rozrywkowych, gdy są w ich sieci domowej.

Większość sieci lokalnych nie ma strefy DNS autorytatywnej, więc urządzenia zamiast tego polegają na mDNS do odkrycia i nawiązania połączenia z innymi urządzeniami lokalnymi. mDNS nie jest wpływany, gdy serwer DNS ZTNA Jamf jest ustawiony w interfejsie sieciowym VPN, pozostawiając to zachowanie do normalnego funkcjonowania.

Polityki dostępu z symbolem wieloznacznym / nie całkowicie ZTNA

Chociaż obietnice bezpieczeństwa ZTNA są atrakcyjne, przejście z szeroko otwartego wdrażania tradycyjnego VPN do zdecentralizowanego środowiska ZTNA na poziomie aplikacji zajmie trochę czasu. Jest nierealistyczne dla większości organizacji oczekiwanie, że będą mogły przejść na VPN oparte na ZTNA (takie jak Jamf) bez niesamowitej ilości testowania z góry i/lub bólu użytkownika.

Dlatego Jamf Connect ZTNA dostosował się do tej rzeczywistości, aby umożliwić mu działanie na wiele podobnych do tradycyjnego VPN na kilka ważnych sposobów.

Symbole wieloznaczne FQDN

Najbardziej zdecentralizowana i najlepsza konfiguracja bezpieczeństwa to skonfigurowanie jak wielu Access Policies, ponieważ masz aplikacje, z konkretnymi FQDN i nazwami hostów używanymi dla każdej. Na przykład dla aplikacji App możesz mieć app.acmeinc.com i images.app.acmeinc.com.

Jednak po prostu odkrycie wszystkich tych nazw hostów, nie mówiąc już o konfiguracji ich w Polityce dostępu, może zająć znaczną ilość czasu.

Dlatego, szczególnie jeśli próbujesz lub właśnie zaczynasz z Jamf Connect ZTNA, zalecamy utworzenie polityki dostępu z nazwą taką jak "Acme Inc Wildcard Default" i skonfigurowanie nazwy hosta, takiej jak *.acmeinc.com. Ta jedyna reguła "złapie" wszystkie żądania wysłane do dowolnego FQDN, który używa acmeinc.com jako swojej domeny.

To świetny sposób na szybkie przygotowanie infrastruktury testowej, dzięki czemu możesz uzyskać ruch przepływający do wewnętrznych aplikacji (zakładając, że skonfigurowałeś odpowiednie Custom DNS Zones i Interconnect Gateways oczywiście).

Jednak będziesz chciał utworzyć polityki dostępu dla twoich szczególnie wrażliwych aplikacji lub innych aplikacji, które odkryjesz, patrząc na FQDN używany dla połączeń zgłoszonych w dziennikach zdarzeń dostępu.

Aby to ułatwić, chmura bezpieczeństwa Jamf pozwala na tworzenie polityk dostępu, które mają nazwy hostów, które znajdują się "w" symbolu wieloznacznym zdefiniowanym w innej polityce dostępu. Na przykład, jeśli odkryjesz, że app.acmeinc.com i images.app.acmeinc.com są ważnymi aplikacjami, dla których chcesz utworzyć określone polityki dostępu, możesz to zrobić bez konieczności dostosowania symbolu wieloznacznego. Po utworzeniu nowej polityki dostępu z tymi bardziej dobrze zdefiniowanymi FQDN, przepływy ruchu będą zaczynać pasować do tej nowej polityki dostępu aplikacji, a nie do polityki wieloznacznej.

Mówiąc prosto, reguła mapowania symbolu wieloznacznego Connect ZTNA pasuje do najbardziej zdecentralizowanej nazwy hosta najpierw. Zakładając, że masz dwie zagnieżdżone polityki wieloznaczne, images.app.acmeinc.com pasowałaby do .app.acmeinc.com przed *.acmeinc.com. Oczywiście, jeśli zdefiniowałeś trzecią politykę dostępu z images.app.acmeinc.com, pokonałaby wszystkie reguły wieloznaczne.

Duże podsieci CIDR oparte na adresach IP

Podobnie jak nazwy hostów, mogą istnieć aplikacje działające przy użyciu połączeń bezpośrednich z adresem IP, które mogą zająć czas odkrycia.

Chociaż zdecydowanie odradzamy definiowanie szerokich segmentów sieciowych (np. 10.0.0.0/8), ponieważ może to umożliwić atakującym poruszanie się bocznie (w centrum danych) i pionowo (w centrach danych) za pośrednictwem połączenia VPN, będzie często potrzeba na początek konfiguracji routingu, która pasuje do tradycyjnego VPN, aby zapewnić bezproblemowy przejście technologii.

Aby zmniejszyć narażenie zalecamy:

• Tylko definiowanie dostępu opartego na IP dla użytkowników lub aplikacji, które absolutnie muszą go mieć
• Utrzymywanie podsieci CIDR jak bliskie adresom /32, jak to możliwe
• Przydzielanie szerokiej polityki dostępu opartej na IP do wąskiej grupy użytkowników pilotażu, a następnie monitorowanie dzienników zdarzeń
  • Odkryj adresy IP, które są używane, i utwórz bardziej wąskie polityki dostępu dla tych
  • Oceń, czy dla użytkowników/aplikacji możliwe jest przejście na FQDN w krótkim lub średnim terminie, pozwalając Ci usunąć potrzebę dostępu opartego na IP na długi termin, aby obsługiwać tę aplikację.

Łączność punktu końcowego do chmury Jamf

Klient Jamf Trust, który jest używany do uwierzytelniania użytkownika i nawiązywania bezpiecznej łączności między punktem końcowym a odpowiednią dzierżawą chmury bezpieczeństwa Jamf, jest w inny sposób dość "głupi" z perspektywy sieciowej.

Zdecydowana większość przetwarzania jest wykonywana w chmurze, z agentem będącym odpowiedzialnym za obsługę zarządzania połączeniami do sieci routingu Jamf i w inny sposób enkapsulowanie i dekapsulowanie pakietów między stosem sieciowym urządzenia a tunelem Wireguard lub HTTP/3.

Szczegóły sieciowe warte wymienienia to aby upewnić się, że przejrzeć wymagania Endpoint Agent Traffic, aby upewnić się, że zapory są skonfigurowane w celu zezwolenia całemu niezbędnemu ruchowi między punktami końcowymi i chmurą bezpieczeństwa Jamf przy użyciu sieci LAN korporacyjnej.

Łączność chmury Jamf do klienta/danych

Gdy ruch punktu końcowego osiąga chmurę Jamf, każdy pakiet podlega weryfikacji kryptograficznej i Access Policies zdefiniowane dla tej dzierżawy i urządzenia. Każda polityka dostępu definiuje trasę "następnego przeskoku" do osiągnięcia aplikacji zdefiniowanej przez politykę, która może być:

• Prywatne połączenie (np. tunel IPSec typu site-to-site)
• Brama NAT egress internetowa (np. zrównoważony zestaw adresów IP z wybranego centrum danych lub automatycznie wybranym na podstawie lokalizacji użytkownika)
• Bezpośrednio z urządzenia samego przy użyciu tras publicznych, a nie routingu przez chmurę bezpieczeństwa Jamf

Ważne jest wskazanie, że wszystkie z powyższych tras następnego przeskoku są dozwolone tylko dla urządzenia, jeśli to urządzenie jest autoryzowane do dostępu do zasobu zgodnie z określoną politykę dostępu. Jeśli urządzenie nie jest dozwolone do osiągnięcia zasobu zgodnie z polityką, to:

• Połączenie jest aktywnie zablokowane/czarnochochone w przypadku, gdy poziom ryzyka urządzenia jest zbyt wysoki
• Połączenie jest traktowane, tak jakby Jamf Connect ZTNA nie było obecne, jeśli urządzenie nie należy do grupy autoryzowanej do dostępu

Urządzenia, które mogą uzyskać dostęp do zasobów, będą korzystać z trasy zdefiniowanej przez politykę dostępu. Podczas gdy ta trasa jest na ogół "dzielona" między wieloma urządzeniami docelowym, silnik polityki Jamf ZTNA zezwala tylko wyraźnie autoryzowanym urządzeniom, użytkownikom i połączeniom w zgodnych kontekstach na korzystanie z tych tras w sposób obsługiwany. W inny sposób te trasy są całkowicie niewidoczne i niedostępne do użycia przez punkty końcowe dzięki fundamentalnej naturze sieci routingu.

Połączenia od serwera/infrastruktury do klienta

W tradycyjnych sieciach VPN, jest technicznie możliwe nawiązanie połączenia z usługami słuchającymi na ich przydzielonych adresach IP VPN. Tradycyjnie był to używany do pulpitu zdalnego/możliwości wsparcia i innych starszych aplikacji.

Jednak ten model dostępu nie jest już uważany za najlepszą praktykę. Dzieje się tak dlatego, że włączenie usług aplikacji na punktach końcowych wiąże się ze znacznymi ryzykami z powodu podatnego oprogramowania, błędów konfiguracji i zarządzania łatami. Te ryzyka mogą umożliwić atakującemu uzyskanie dostępu do punktu końcowego, ostatecznie uzyskanie dostępu do danych lokalnych, a także służące jako brama do danych korporacyjnych i infrastruktury za pośrednictwem połączenia VPN punktu końcowego.

Zamiast tego wiele z tych narzędzi zostało zmodernizowane, aby korzystać z podobnej architektury "obsługiwanego połączenia", tak że punkt końcowy tworzy gniazdo wychodzące do usługi, a usługa następnie łączy połączenie razem z drugą łączącą się stroną na żądanie. To umożliwia punktowi końcowemu efektywne działanie w trybie "tylko wychodzącym", zezwalając praktycznie wszystkim portom przychodzącym i protokołom, które mają być zablokowane na urządzeniu.

Z tych powodów Jamf nie obsługuje połączeń od infrastruktury do punktu końcowego. To dramatycznie zmniejsza powierzchnię ataku punktów końcowych, podczas gdy punkt końcowy nadal ma pełny dostęp do wszystkich aplikacji, których użytkownik musi być produktywny.

Walidacja i testowanie łączności

Sekcje poniżej są zaprojektowane, aby pomóc Ci lepiej testować, diagnozować i rozwiązywać problemy przepływów danych Jamf Connect ZTNA.

Rejestrowanie aplikacji Jamf Trust

Zarówno macOS, jak i wersje aplikacji Jamf Trust dla Windows zawierają możliwość eksportowania danych dziennika do lokalnego archiwum na urządzeniu. Ten plik jest pozbawiony wszystkich sekretów, ale zawiera przydatne informacje o stanie konfiguracji urządzenia oraz poza pasmem dzienniki komunikacji między klientem a serwerem w celu rozwiązania problemów.

Testowanie z łącznością Netcheck

Aplikacja NetCheck Connectivity app dla iOS i macOS (uniwersalna aplikacja) to przydatne narzędzie firm trzecich zbudowane do diagnozowania stanu stosu sieciowego urządzenia, a także zapewniające możliwość sondowania określonego punktu końcowego, aby sprawdzić, czy będzie kierowany przez Jamf ZTNA, czy nie.

To narzędzie jest bardzo przydatne do weryfikacji problemów zgłaszanych przez użytkowników końcowych, gdy w inny sposób nie możesz uzyskać rąk na urządzeniu. Użytkownicy mogą łatwo uzyskać aplikację z App Store dla obu platform, otworzyć test (automatycznie kopując test), a następnie udostępnić wyniki przy użyciu arkusza udziału, który pakuje wyniki do pliku JSON).

Testowanie z ping

Najczęściej popełniany błąd to to, że po skonfigurowaniu wszystkiego prawidłowo w chmurze bezpieczeństwa Jamf (bez definiowania bezpośrednich adresów IP lub wyboru zgodnego routingu IPv4), tester wyda następujące polecenie w narzędziu wiersza polecenia wybranym:

ping app.acmeinc.com

Co potem wraca z czymś w rodzaju:

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

"Co?! To wszystko jest zepsute!"

Problem tutaj polega na tym, że ping jako narzędzie nie jest natywnie IPv6 świadome. W szczególności ping będzie wystawiać tylko A rekordy zapytania dla wprowadzonego FQDN, które szybko się nie powiedzie. Jest to mało prawdopodobne wszystko inne aplikacje i przeglądarki, które polegają na systemie operacyjnym do wykonywania wyszukiwań, które wyślą z góry A/AAAA/HTTPS pytań DNS.

Dlatego naprawka jest łatwa, użyj ping6 aby wymusić użycie IPv6:

#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

Tak długo, jak app.acmeinc.com jest w stanie odpowiedzieć na żądania ICMP ping, powyższa odpowiedź będzie otrzymana. Notatka: nie ma żadnego wskazania wewnętrznego adresu IP serwera 10.0.1.22.

Testowanie z dig/nslookup

Podobnie do testowania z ping, dig i nslookup domyślnie podczas korzystania z wiersza polecenia:

# 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
...

Podobnie jak przy ping, będziesz musiał wyraźnie wskazać, że chcesz wyszukać nazwę hosta za pomocą zapytań AAAA:

# 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
...

I tylko dla zabawy, nslookup ma inny przełącznik wiersza polecenia i składnię (aaaa małymi literami).

# 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: Zabawny fakt: Dlaczego mamy ping i ping6 jako oddzielne polecenia?

Zgodnie ze stroną podręcznika ping6:

Narzędzie ping6 jest celowo oddzielone od ping(8).

Było wiele dyskusji na temat tego, dlaczego oddzielamy ping6 i ping(8). Niektórzy ludzie argumentowali, że byłoby wygodniej ujednolicić polecenie ping dla zarówno IPv4, jak i IPv6. Poniższe są odpowiedzią na prośbę.

Z punktu widzenia dewelopera: ponieważ podstawowy surowy API gniazd jest całkowicie różny między IPv4 i IPv6, skończylibyśmy z dwoma typami bazy kodu. Byłoby faktycznie mniej korzyści do ujednolicenia dwóch poleceń w jedno polecenie z punktu widzenia dewelopera.

Z punktu widzenia operatora: w przeciwieństwie do zwykłych aplikacji sieciowych, takich jak narzędzia zdalnego logowania, zwykle jesteśmy świadomi rodziny adresów przy korzystaniu z narzędzi zarządzania siecią.
Nie tylko chcemy wiedzieć o dostępności hosta, ale chcemy wiedzieć o dostępności hosta za pośrednictwem konkretnego protokołu sieciowego, takiego jak IPv6. Tak więc, nawet jeśli mieliśmy ujednolicone polecenie ping(8) dla zarówno IPv4, jak i IPv6, zwykle wpisalibyśmy opcję -6 lub -4 (lub coś podobnego), aby określić konkretną rodzinę adresów. To zasadniczo oznacza, że mamy dwa różne polecenia.

Microsoft i twórcy nslookup myśleli inaczej!

FAQ

P: Dlaczego nie mogę nawiązać połączenia z moją aplikacją lub zasobem danych?! Oto kilka sugerowanych kroków do wykonania:

1. Upewnij się, że używasz właściwej wersji ping, jeśli testujesz w ten sposób.
2. Użyj Netcheck, aby wyeliminować wszelkie problemy po stronie klienta
   1. Jeśli Netcheck pracował, prawdopodobnie jest problem z buforowaniem DNS. Uruchom ponownie przeglądarkę/aplikację i/lub wydaj następujące polecenie macOS: sudo killall -HUP mDNSResponder;sudo killall mDNSResponderHelper;sudo dscacheutil -flushcache. Aby zmniejszyć problemy z buforowaniem, zaleca się pozostawienie Jamf Connect ZTNA włączonego.
3. W chmurze bezpieczeństwa Jamf / RADAR sprawdź dzienniki zdarzeń dostępu pod kątem błędów lub aktywności.
   1. Jeśli widzisz wpisy w dzienniku zdarzeń, oznacza to, że DNS poprawnie się rozwiązuje i istnieje prawdopodobnie problem z routingiem lub siecią/zaporą sieciową ACL z źródłem lub docelowymi adresami IP.
   2. Jeśli nie widzisz wpisów, sprawdź, czy ruch sieciowy klienta Jamf wychodzący nie jest blokowany przez Twoją sieć na podstawie przewodnika Endpoint Agent Traffic.
4. Jeśli docelowa aplikacja ma być dostępna za pośrednictwem tunelu IPSec:
   1. Potwierdź, że tunel jest "w górze" zgodnie z chmurą bezpieczeństwa Jamf / RADAR i Twoją stroną połączenia zapory. Jeśli wyłączone, te przewodniki mogą być pomocne do weryfikacji konfiguracji.
   2. Potwierdź, że możesz ping adres IP testu "Jamf Side" podany w chmurze bezpieczeństwa Jamf / RADAR dla połączenia IPSec z urządzenia kończącego tunel po Twojej stronie.
      1. Jeśli to działa, ale nie możesz ping ten sam adres IP z innych urządzeń w sieci, prawdopodobnie brakuje Ci wewnętrznych konfiguracji routingu. Musisz upewnić się, że podsieci IP Jamf są kierowane do urządzenia/urządzenia obsługującego Twoją stronę tunelu.

Jeśli potrzebujesz dalszej pomocy, nie wahaj się skontaktować z pomocą techniczną Jamf.

P: Mam politykę dostępu aplikacji z konkretnymi grupami skonfigurowanymi, aby zezwolić na korzystanie z tej aplikacji. Co się dzieje z ruchem, który jest otrzymywany od użytkownika/urządzenia, które NIE jest w tej grupie? Ruch z nieprzydzielonych urządzeń jest obsługiwany, tak jakby polityka dostępu do aplikacji nie istniała. Innymi słowy, publiczna odpowiedź DNS - jeśli istnieje - jest zwracana do urządzenia, a nie efemeryczny adres IPv6.

P: Mam sprzęt WiFi Cisco Meraki i moje połączenia Jamf ZTNA sporadycznie przestają działać. Co jest nie tak? Funkcja "Layer 7 Statistical AI" Meraki błędnie i sporadycznie blokuje ruch Wireguard Jamf jako P2P. Prosimy o kontakt z pomocą techniczną Meraki w celu uzyskania pomocy w zarządzaniu tym ustawieniem, jeśli ma to wpływ na Twoje środowisko.