Konfiguracja provisioningu Sophos Connect z .pro

Plik provisioningu Sophos Connect z rozszerzeniem .pro nie jest kompletnym profilem VPN. Informuje klienta Windows, przez który portal VPN ma pobrać konfiguracje IPsec i SSL VPN. Po pomyślnym zalogowaniu do portalu Sophos Connect importuje plik .scx, a jeśli użytkownik jest przypisany do polityki SSL VPN — również plik .ovpn. Samo pojawienie się profilu nie oznacza jeszcze, że uwierzytelnienie tunelu lub dostęp do zasobów wewnętrznych są dozwolone.

Jest to szczególnie praktyczne, gdy profile mają być dystrybuowane centralnie, a późniejsze zmiany pobierane automatycznie. Portal VPN staje się jednak częścią produkcyjnej ścieżki logowania. Jego dostępność, certyfikat, MFA, przypisanie użytkowników i zabezpieczenie są zatem równie ważne jak składnia JSON pliku.

⚠️ Jeżeli użytkownicy zewnętrzni mają przeprowadzać provisioning z sieci WAN, portal VPN musi być dostępny z WAN. Zwiększa to publicznie dostępną powierzchnię ataku. Przed wdrożeniem należy zapewnić zaufany certyfikat, MFA, możliwie restrykcyjne reguły Local Service ACL, przetestowane blokady logowania oraz ścieżkę awaryjną z profilem rozprowadzanym ręcznie.

Provisioning w ośmiu krokach

1. W pełni skonfigurować IPsec Remote Access lub SSL VPN na zaporze i przetestować za pomocą ręcznie zaimportowanego pliku.
2. Udostępnić portal VPN pod zaufaną nazwą FQDN i z zaufanym certyfikatem.
3. W Administration > Device access włączyć portal VPN tylko dla wymaganych stref. Ograniczenie dostępu do określonych sieci źródłowych wymaga dodatkowo odpowiedniej reguły wyjątku Local Service ACL.
4. Utworzyć minimalny plik .pro z polami display_name, gateway i vpn_portal_port.
5. Dodać MFA, auto-connect i kolejność bram dopiero po ustaleniu odpowiedniego procesu.
6. Najpierw ręcznie zaimportować plik dla użytkownika pilotażowego i osobno przetestować IPsec oraz SSL VPN.
7. Następnie przekazać zatwierdzony plik .pro do zarządzanego wdrożenia Windows i zacząć od małej grupy pilotażowej.
8. Zweryfikować logowanie do portalu, zaimportowane profile, tunel, cele wewnętrzne, logi, aktualizacje profili i wycofanie zmian.

Kiedy plik .pro jest odpowiedni

Provisioning dobrze sprawdza się na zarządzanych urządzeniach Windows, które używają Sophos Connect do IPsec, SSL VPN lub obu metod. Po zalogowaniu do portalu zapora udostępnia profil IPsec wszystkim użytkownikom. Nie oznacza to, że każdy użytkownik może pomyślnie uwierzytelnić tunel lub uzyskać dostęp do zasobów wewnętrznych. Konfiguracja SSL VPN jest importowana tylko wtedy, gdy użytkownik należy do odpowiedniej polityki SSL VPN.

Przy pierwszym provisioningu SFOS może automatycznie utworzyć użytkownika katalogowego, który nie istnieje jeszcze lokalnie, i przypisać go do grupy zgodnie z mapowaniem serwera uwierzytelniania. Użytkownik nie musi wcześniej logować się do portalu VPN ani portalu użytkownika. Automatyczne utworzenie nie zastępuje sprawdzenia kolejności grup i rzeczywistych uprawnień VPN.

Ręczne pliki .scx i .ovpn pozostają przydatne, jeśli VPN Portal nie powinien być publicznie dostępny, klientów jest niewielu lub portal stanowi niepożądaną dodatkową zależność. .pro pobiera IPsec (.scx) i konfiguracje SSL VPN dozwolone dla użytkownika (.ovpn) przez VPN Portal, a także późniejsze zmiany; sam nie jest profilem tunelu. Obsługiwane są zgodne klienty Windows oraz Sophos Connect dla macOS od 2.1, ale nie klient macOS 2.0 ani starszy. Provisioning IPsec wymaga Sophos Connect 2.1 lub nowszego. W kliencie macOS 2.0 nadal konieczne są bezpośredni import i kontrolowane ręczne aktualizacje.

Aktualizacja datowanej obserwacji: informacje o wydaniu Sophos wymieniają Sophos Connect 2.1 dla macOS, opublikowany 6 października 2026 r., z provisioningiem .pro, Entra ID SSO i natywnym ARM. Obserwacja z 24 września 2026 r. opisuje ówczesny stan. Sprawdź wersję faktycznie dostępnego instalatora; publikacja nie dowodzi, że portal firewalla już udostępnia ten pakiet lub że został przetestowany na konkretnym urządzeniu.

Właściwą konfigurację VPN opisują osobne instrukcje: Konfiguracja Sophos Connect IPsec na zaporze i Konfiguracja zdalnego dostępu SSL VPN.

Wymagania i wartości przykładowe

Poniższy przykład używa publicznej nazwy portalu vpn.example.com oraz wewnętrznego hosta kontrolnego intranet.corp.example. Obie nazwy są symboliczne:

• vpn.example.com należy zastąpić rzeczywistym FQDN portalu VPN, prawidłowo rozwiązywanym publicznie i wewnętrznie. Certyfikat portalu musi być ważny dla tej nazwy i zaufany przez klientów.
• intranet.corp.example należy używać jako auto_connect_host tylko wtedy, gdy host jest stabilnie dostępny i odpowiada wyłącznie z sieci wewnętrznej. Publiczny lub niestabilny host zafałszowałby rozpoznawanie sieci.
• Port 443 jest domyślnym portem portalu VPN. Jeśli zapora używa innego portu, ta sama wartość musi znaleźć się w vpn_portal_port.

Przed utworzeniem pliku należy pomyślnie przetestować co najmniej następujące elementy:

• Docelowy profil IPsec lub SSL VPN działa po ręcznym imporcie.
• Portal VPN jest dostępny przez planowany FQDN i używa kompletnego łańcucha certyfikatów.
• Użytkownicy, grupy główne, polityka SSL VPN i metody uwierzytelniania są zgodne.
• W provisioningu SSO portal VPN, IPsec i SSL VPN używają tego samego skonfigurowanego serwera dostawcy tożsamości (IdP) w Authentication > Services: Microsoft Entra ID w dokumentacji SFOS 22 lub obsługiwanego IdP OpenID Connect (OIDC) w SFOS 23.
• gateway odpowiada nazwie FQDN lub adresowi IP zapory skonfigurowanemu w sekcji Redirect URI serwera IdP. Wpisz tylko ten host, nie pełny URI wywołania zwrotnego ze schematem, portem i ścieżką; port portalu ustaw osobno w vpn_portal_port.
• Działają MFA oraz test negatywny z nieuprawnionym użytkownikiem.

Przy publikacji portalu pomaga Device Access i Local Service ACL. Ochrona portalu VPN przed brute force opisuje powtarzające się nieudane logowania i zabezpieczenie portalu dostępnego z WAN.

Wybór wersji SSO i dostawcy

Dla Windows z Sophos Connect 2.4 lub nowszym SFOS 22 opisuje Entra ID SSO; SFOS 23 rozszerza zakres na obsługiwanych dostawców OIDC. Nie oznacza to obsługi każdego dostawcy OIDC ani potwierdzonej dostępności w konkretnej kompilacji firmware. Użyj właściwej gałęzi wersji w Entra ID VPN SSO lub konfiguracji Google Workspace OIDC dla SFOS 23. Google wymaga prawidłowej publicznej nazwy FQDN dla przekierowań, nie adresu IP. Te poradniki obejmują konfigurację dostawcy, przypisanie usług i diagnostykę.

Przed bezpośrednim pobraniem .scx lub .ovpn bez .pro wybierz IdP w Authentication > Services, a dopiero potem pobierz profil. SSL VPN musi używać tego samego IdP dla portalu i tunelu; bezpośredni IPsec może używać tego samego lub innego IdP. Nie stosuj tego wyjątku IPsec do provisioningu.

Dla macOS 2.1 lub nowszego poradnik klienta wskazuje Entra ID SSO, nie ogólną obsługę OIDC. Zapisane wymagania i poradnik klienta różnią się zakresem informacji o macOS; osobno potwierdź i przetestuj planowaną kombinację firmware, klienta i VPN. Pole przeglądarki macOS poniżej pozostaje właściwe tylko dla Entra; GPO, automatyzacja folderu importu i skrypty logowania pozostają właściwe tylko dla Windows.

Tworzenie pliku provisioningu

Plik .pro to JSON. gateway jest jedynym wymaganym polem. Należy jednak wyraźnie ustawić nazwę wyświetlaną i port portalu, tak aby konfiguracja mogła zostać jednoznacznie zweryfikowana. Utwórz plik z edytorem tekstu i zapisz go na przykład jako avanet-vpn.pro.

Minimalny profil dla jednej bramy

[
  {
    "display_name": "Avanet Remote Access",
    "gateway": "vpn.example.com",
    "vpn_portal_port": 443,
    "otp": false,
    "auto_connect_host": "",
    "can_save_credentials": false,
    "check_remote_availability": true,
    "run_logon_script": false
  }
]

display_name może mieć maksymalnie 60 znaków. Bez nazwy wyświetlanej Sophos Connect pokazuje wartość gateway. Ustawienie can_save_credentials na true pozwala użytkownikowi zapisać nazwę użytkownika i hasło; ustawienie nie dotyczy SSO. Zezwolenie na zapis danych logowania jest decyzją bezpieczeństwa, a nie domyślnym udogodnieniem.

Pola, których nie określono, przyjmują wartości domyślne producenta. W przykładzie wszystkie pola ustawiono jawnie, aby podczas przeglądu nie pominąć wartości niejawnych:

Przy włączonym check_remote_availability klient sprawdza dostępność podczas uruchamiania połączenia. run_logon_script dotyczy tylko Sophos Connect dla Windows; dopuszczalne wartości to true i false, a wartością domyślną jest false. Uruchamia skrypt logowania udostępniony przez kontroler domeny po zestawieniu tunelu. Skrypt pozostaje wyłączony, dopóki test pilotażowy nie potwierdzi jego potrzeby i działania.

Starsza składnia user_portal_port jest nadal akceptowana, ale również oznacza obecnie port portalu VPN. Dla nowych plików bardziej jednoznaczne jest vpn_portal_port.

Wybór przeglądarki Entra ID SSO w macOS

Opcjonalne pole sso_auth_browser_type dotyczy wyłącznie Microsoft Entra ID SSO z Sophos Connect dla macOS w wersji 2.1 lub nowszej. Nie jest ustawieniem Windows ani ogólną opcją przeglądarki dla innych dostawców tożsamości. Dopuszczalne wartości należy zapisać dosłownie:

• auto: wartość domyślna; używa wbudowanej przeglądarki i w razie potrzeby może przejść do przeglądarki systemowej.
• embedded: używa przeglądarki wbudowanej w Sophos Connect.
• system: używa domyślnej przeglądarki systemu operacyjnego.

Jeśli pole zostanie pominięte lub zawiera nieprawidłową wartość, Sophos Connect używa auto. W odpowiedniej konfiguracji Entra na macOS można dodać tę opcjonalną właściwość do obiektu połączenia w pliku .pro:

"sso_auth_browser_type": "auto"

To tylko fragment JSON, a nie kompletny plik .pro. Właściwość należy umieścić obok gateway w istniejącym obiekcie; właściwości rozdziela się przecinkami, bez przecinka po ostatniej. auto jawnie wskazuje wartość domyślną na potrzeby przeglądu; embedded lub system ustawia się tylko dla świadomie wybranego i sprawdzonego w pilotażu procesu przeglądarki. Sophos Connect na macOS opisuje import i interaktywne logowanie; składnia pola pozostaje opisana tutaj.

Prawidłowe planowanie automatycznego łączenia

auto_connect_host pomaga Sophos Connect rozpoznać, czy klient znajduje się już w sieci wewnętrznej. Gdy interfejs sieciowy otrzyma nowy lub zmieniony adres IP, klient sprawdza ten host. Jeśli host nie jest dostępny, połączenie zostaje aktywowane. Tunel zestawia się automatycznie, jeśli zapisano dane logowania lub ostatnio użyto SSO.

"auto_connect_host": "intranet.corp.example"

Host kontrolny nie jest ogólnym testem stanu Internetu. Musi być stabilny, rozwiązywany wewnętrznie i niedostępny z zewnątrz. Przed wdrożeniem testuje się go zarówno w sieci firmowej, jak i z sieci zewnętrznej. Pusty ciąg "" wyłącza automatyczne łączenie.

W przypadku działania always-on zapisane dane logowania, SSO, MFA i zachowanie po zmianach sieci muszą być ze sobą skoordynowane. Automatyczne uruchamianie SSL VPN z automatycznym logowaniem wyjaśnia różnice.

Używanie wielu bram

Wiele bram portalu wprowadza się jako tablicę. gateway_order określa tylko sposób wyboru portalu przez Sophos Connect do pobrania konfiguracji. Późniejszy tunel korzysta z bram zapisanych w zaimportowanej konfiguracji .scx lub .ovpn.

[
  {
    "display_name": "Avanet Remote Access",
    "gateway_order": "in_order",
    "gateway": [
      "vpn-zrh.example.com",
      "vpn-ber.example.com"
    ],
    "vpn_portal_port": 443,
    "otp": false,
    "can_save_credentials": false,
    "check_remote_availability": true,
    "run_logon_script": false
  }
]

Tryby wyboru mają różne skutki operacyjne:

• in_order próbuje wpisów w zdefiniowanej kolejności.
• latency wybiera bramę według czasu odpowiedzi na próbę połączenia TCP.
• distributed wybiera losowo bramę podczas próby połączenia.

Kolejność nie zastępuje przetestowanego projektu WAN, DNS ani HA. Każda podana nazwa portalu wymaga ważnego certyfikatu, odpowiedniej dostępności i tej samej oczekiwanej zawartości provisioningu.

Należy od tego odróżnić wiele połączeń. Dwa oddzielne obiekty w zewnętrznej tablicy JSON tworzą dwa wpisy w Sophos Connect, na przykład jeden dla pracowników, a drugi dla administratorów. Natomiast pojedynczy obiekt z wieloma wartościami w polu gateway pozostaje jednym połączeniem z alternatywnymi bramami provisioningu. Przed połączeniem obu wariantów należy ustalić nazwy, grupy docelowe i ścieżki awaryjne.

Świadome ustawianie pól MFA

Przy otp: true Sophos Connect wyświetla trzecie pole wprowadzania. 2fa określa sposób wysłania jego zawartości do serwera uwierzytelniania:

• 2fa: 1 używa konfiguracji Sophos Firewall. Hasło i OTP są łączone jako passwordotp.
• 2fa: 2 używa zewnętrznej usługi, takiej jak Duo. Hasło i kod są rozdzielone przecinkiem; zależnie od konfiguracji Duo możliwe są także push, phone, sms lub kod tokena.

[
  {
    "display_name": "Avanet Remote Access MFA",
    "gateway": "vpn.example.com",
    "vpn_portal_port": 443,
    "otp": true,
    "2fa": 1,
    "can_save_credentials": false,
    "check_remote_availability": true,
    "run_logon_script": false
  }
]

Przy pierwszym pobraniu ekran logowania może pojawić się dwukrotnie: raz w celu pobrania konfiguracji, a następnie w celu zestawienia tunelu. Nie oznacza to automatycznie błędu. Helpdesk powinien znać to zachowanie przed szerokim wdrożeniem. Konfigurację MFA po stronie zapory opisuje Konfiguracja MFA na Sophos Firewall.

Poniższe kroki GPO i folderu importu dotyczą Windows. W macOS od 2.1 zaimportuj zatwierdzoną .pro bezpośrednio do klienta i osobno przetestuj pakiet, dostęp do portalu, pobranie profilu i połączenie VPN; nie przenoś ścieżek Windows ani kroków GPO na Mac.

Import w Windows i przekazanie do zarządzanego wdrożenia

Plik można udostępnić przez chronione pobieranie i zaimportować ręcznie. Użytkownicy wybierają Import connection albo dwukrotnie klikają plik .pro. E-mail jest odpowiedni tylko przy kontrolowanym transporcie i odbiorcach; w pliku nie wolno umieszczać haseł, OTP ani tokenów użytkowników.

Sophos Connect monitoruje następujący folder importu:

C:\Program Files (x86)\Sophos\Connect\import\

Umieszczony w nim plik .pro jest automatycznie importowany, a następnie usuwany. Jest to normalne i nie dowodzi, że uwierzytelnianie lub tunel działają. To przekazanie przez folder stanowi interfejs do zarządzanej dystrybucji.

Skrypty startowe GPO, pakiet klienta, SCCLI, kody wyjścia i pełny rollback opisuje Zarządzane wdrożenie Sophos Connect w Windows. W tym procesie zatwierdzony .pro jest osobnym, wersjonowanym artefaktem przekazywanym do zainstalowanego klienta, co oddziela weryfikację pakietu od provisioningu.

W pilocie udokumentować zatwierdzoną wersję lub hash, przekazać plik do folderu importu i sprawdzić, jakie połączenie się pojawi. Źródło powinno być czytelne tylko dla właściwych urządzeń, używać zaufanego certyfikatu i nie zawierać danych logowania w URL ani skrypcie. Instalacja Sophos Connect w Windows opisuje instalację i wspierane platformy.

Plik .pro zwykle nie zawiera haseł użytkowników. Nadal jest jednak kontrolowanym artefaktem konfiguracyjnym: adresy portalu, zachowanie, MFA i ustawienia auto-connect powinny pochodzić wyłącznie z autoryzowanego źródła.

Metadane .pro wielokrotnego użytku i tożsamość SSL

Oryginalny plik .pro zawiera metadane provisioningu wielokrotnego użytku, nie certyfikat SSL VPN ani klucz prywatny użytkownika. Dokumentacja klienta SFOS 22 odróżnia go od profilu SSL generowanego podczas importu: profil i jego certyfikaty są powiązane z tożsamością, metodą uwierzytelniania i domeną użytymi przy imporcie. Dla innej metody lub domeny zaimportuj osobny .pro lub własny .ovpn użytkownika; ponowne użycie zaimportowanego profilu SSL może spowodować Login failed. Wrong fingerprint of certificate. To udokumentowane ograniczenie nie dotyczy profili IPsec .scx.

Plik .ovpn zawiera certyfikaty i klucze prywatne właściwe dla użytkownika: nigdy nie udostępniaj go innym użytkownikom. Ponowne użycie zatwierdzonych oryginalnych metadanych .pro nie oznacza współdzielenia wygenerowanego profilu SSL ani eksportowania cudzych kluczy. Import i logowanie w Windows oraz w macOS opisują kroki klienta; stosuj to zastrzeżenie wersji do wskazówek dotyczących powiązania SSL i odcisku certyfikatu.

Zapisana dokumentacja klienta SFOS 23 pomija sekcję SFOS 22 o powiązaniu tożsamości, nie wyjaśniając zmiany działania produktu. Pominięcie nie dowodzi ani swobodniejszego ponownego użycia, ani niezmienionego powiązania we wszystkich wersjach. Do czasu uzyskania autorytatywnego wyjaśnienia dla konkretnej wersji rozdzielaj importy SSL według tożsamości, metody i domeny jako środek ostrożności; nie przedstawiaj go jako zweryfikowanej reguły działania SFOS 23.

Zmiany i aktualizacje profili

Po pomyślnym imporcie Sophos Connect automatycznie pobiera dostępne profile .scx i .ovpn oraz późniejsze zmiany. Nadal trzeba odróżniać ścieżkę pobierania w .pro od pobranego profilu VPN:

• Jeśli zmieni się gateway lub vpn_portal_port, należy zaktualizować i ponownie rozprowadzić plik .pro.
• Jeśli zmieni się port lub protokół w SSL VPN global settings, użytkownicy muszą kliknąć ikonę koła zębatego danego połączenia w kliencie i wybrać Update policy.
• Inne zmiany udostępnionego profilu VPN klient pobiera automatycznie. Zmiany bramy, certyfikatu serwera, portu lub protokołu SSL VPN mogą wymagać ponownego logowania.
• Jeśli po przywróceniu lub imporcie wartości gateway i portu portalu VPN pozostają niezmienione, plik automatycznie ponownie pobiera odpowiednie konfiguracje IPsec i SSL VPN.
• Jeśli ścieżka uległa zmianie, należy ponownie rozprowadzić i zaimportować plik .pro.
• Bez działającego .pro trzeba ponownie zaimportować konfiguracje IPsec; po zmianie portu, protokołu, interfejsu lub certyfikatu serwera SSL VPN ponownie pobrać i zaimportować .ovpn.
• Aktualizacja klienta nie zastępuje kontrolowanej redystrybucji zmienionego pliku .pro.

Nie należy równolegle rozprowadzać starych i nowych plików provisioningu przez różne GPO, pliki do pobrania i wiadomości e-mail. Dla każdego wdrożenia dokumentuje się nazwę pliku, wersję lub datę modyfikacji, grupę docelową i ścieżkę awaryjną.

Weryfikacja provisioningu i tunelu

Test przeprowadza się z uprawnionym i nieuprawnionym użytkownikiem z rzeczywistej sieci zewnętrznej. Pomyślne logowanie do portalu nie jest jeszcze pomyślnym testem VPN.

1. Sprawdzić wersję Sophos Connect i platformę Windows.
2. Zaimportować plik .pro ręcznie lub za pośrednictwem pilotażowej GPO.
3. Sprawdzić, które połączenia .scx i .ovpn rzeczywiście się pojawiają.
4. Przejść cały proces MFA, w tym ewentualne drugie logowanie.
5. Połączyć się osobno przez IPsec i SSL VPN, jeśli dostępne są oba typy połączeń.
6. Sprawdzić przydzielony adres, wewnętrzne rozwiązywanie nazw DNS, serwer docelowy, regułę zapory i ścieżkę powrotną.
7. W przypadku nieuprawnionego użytkownika należy odróżnić import profilu od dostępu: profil IPsec może się pojawić, ale zestawienie tunelu lub dostęp do zasobów wewnętrznych musi zostać odrzucony na przewidzianym etapie uwierzytelniania lub stosowania polityki. Plik SSL VPN .ovpn nie może zostać zaimportowany bez odpowiedniej polityki.
8. Przetestować obie ścieżki aktualizacji: normalna zmiana profilu musi pojawić się automatycznie przez zaimportowany .pro; po zmianie portu lub protokołu SSL VPN wybrać w kliencie Update policy.
9. Sprawdzić restart klienta, zmianę sieci i ponowne przekazanie wybraną metodą.
10. Przetestować ręczny powrót do zatwierdzonego profilu .scx lub .ovpn.

W przypadku Microsoft Entra ID SSO dodatkowo sprawdza się Redirect URI, Conditional Access i wymuszone ponowne logowanie na współdzielonych endpointach. Microsoft Entra ID SSO dla Sophos Connect i portalu VPN wyjaśnia pełne mapowanie.

W pilotażu SSO zapisz wersję firmware, wersję klienta i IdP. Użyj wybranej powyżej gałęzi wersji, sprawdź przypisanie tego samego IdP do usług provisioningu i osobno przetestuj pobieranie z portalu oraz tunel z uprawnionymi i nieuprawnionymi użytkownikami. Wskazówki dotyczące tożsamości SSL pozostają ograniczone do udokumentowanej wersji; udany pilotaż nie rozwiązuje ogólnie otwartego konfliktu w dokumentacji źródłowej SFOS 23.

Systematyczne zawężanie błędów

Żadne połączenie nie jest importowane

Najpierw sprawdzić, czy plik zawiera prawidłowy JSON, kończy się na .pro i został zaimportowany przez klienta. Następnie zweryfikować gateway, vpn_portal_port, DNS, łańcuch certyfikatów i dostępność portalu VPN. Zniknięcie pliku z folderu importu oznacza jego przetworzenie, ale nie dowodzi pomyślnego uwierzytelnienia.

Jeśli klient dociera do portalu, lecz nie otrzymuje profilu, należy sprawdzić skonfigurowane połączenie IPsec, politykę SSL VPN, członkostwo w grupach i metody uwierzytelniania. Plik IPsec .scx jest udostępniany wszystkim użytkownikom; plik SSL VPN .ovpn tylko członkom odpowiedniej polityki.

Błędy certyfikatu lub SSO

Publiczna nazwa w gateway musi odpowiadać certyfikatowi i hostowi zapory w sekcji Redirect URI skonfigurowanego IdP. Sprawdź vpn_portal_port osobno. W provisioningu SSO portal VPN, IPsec i SSL VPN muszą używać tego samego IdP. Osobno zweryfikuj pobieranie z portalu i uwierzytelnianie tunelu dla wybranej gałęzi SFOS/klient/dostawca; widoczny profil ani udany Test connection nie dowodzą żadnego z nich.

Dla Entra skoreluj próbę z Entra sign-in log, uwzględniając MFA i Conditional Access. Korzystaj z diagnostyki właściwej dla wersji w Entra ID VPN SSO: starsze nazwy logów SSO dotyczą SFOS 22, nie każdego wdrożenia OIDC. Dla Google w SFOS 23 korzystaj z diagnostyki Google Workspace OIDC. Nie przenoś między wersjami instrukcji logów ani restartów właściwych dla dostawcy.

MFA pojawia się dwa razy lub nie działa

Przy pierwszym pobraniu można oczekiwać dwóch logowań. W razie niepowodzenia należy porównać otp, 2fa, skonfigurowaną metodę MFA Sophos lub zewnętrzną oraz oczekiwany format danych. passwordotp i zewnętrzna metoda rozdzielana przecinkiem nie są zamienne.

Profil istnieje, ale ruch nie działa

Provisioning przeszedł wtedy dalej niż rzeczywisty punkt awarii. Osobno sprawdzić pulę adresów, trasy klienta, DNS, regułę zapory, NAT, trasę powrotną i packet capture. Dla IPsec kontynuować w Rozwiązywanie problemów z VPN IPsec na Sophos Firewall.

Zarządzane przekazanie nie importuje pliku

Najpierw przetestować ręczny import tego samego zatwierdzonego pliku. Jeśli działa, błąd dotyczy przekazania, a nie schematu .pro. Sprawdzić stan usługi, kontekst systemowy, dostęp do źródła, uprawnienia i dokładną ścieżkę. Diagnostykę pakietu, GPO i SCCLI kontynuować w artykule o zarządzanym wdrożeniu Windows. Ślepa redystrybucja nie zastępuje diagnostyki.

Bezpieczny rollback

Podczas wycofywania najpierw zatrzymać dystrybucję do odpowiedniej grupy, aby nie doszło do kolejnego importu. Zatrzymanie przekazania nie kasuje już zaimportowanych połączeń. Na urządzeniach pilotażowych trzeba je kontrolowanie usunąć lub zastąpić przed zaimportowaniem i przetestowaniem wcześniej zatwierdzonego pliku .scx lub .ovpn. Zmiany w portalu VPN, Device Access lub uwierzytelnianiu wycofać dopiero, gdy nie zależy od nich produkcyjny provisioning.

Na klientach testowych w kontrolowany sposób usunąć i ponownie zaimportować istniejące połączenie Sophos Connect. Następnie powtórzyć logowanie do portalu, test tunelu, DNS, celów wewnętrznych i test negatywny. Wadliwy plik .pro usunąć z centralnych repozytoriów i dystrybucji oprogramowania dopiero po potwierdzeniu ścieżki awaryjnej.

FAQ