Sophos Firewall: brak pliku .ovpn lub 0 bajtów

Jeśli Sophos Firewall VPN Portal nie dostarcza użytecznego pliku .ovpn, najpierw trzeba dokładnie ustalić objaw. Trzy przypadki wyglądają podobnie, ale mają różne przyczyny:

Opcja pobrania w ogóle nie jest dostępna: Najczęściej użytkownik nie jest przypisany do odpowiedniej policy SSL VPN albo oczekiwane członkostwo w grupie nie jest uwzględniane.
Opcja pobrania jest widoczna, ale plik ma 0 bajtów albo zawiera tylko komunikat o błędzie: Wygenerowanie lub udostępnienie profilu nie powiodło się. Istotne są wtedy generowanie certyfikatu, logi, wersja firmware oraz aktywny node w przypadku HA.
Plik nie jest pusty, ale istniejące połączenie przestało działać: Zazwyczaj nie jest to błąd pobierania. Po zmianie Protocol, SSL server certificate, Override hostname lub Port trzeba zaimportować aktualny profil.

Takie rozróżnienie pozwala uniknąć niepotrzebnych ingerencji. W szczególności nie należy odnawiać Default CA na podstawie przypuszczeń ani wykonywać starych poleceń naprawczych z wpisów Community.

Klasyfikacja objawu w VPN Portal

Podczas pierwszej kontroli należy zalogować się do VPN Portal jako użytkownik, którego dotyczy problem, i otworzyć VPN > VPN configuration. Następnie oddzielnie zapisuje się cztery wyniki: portal jest dostępny, logowanie się powiodło, wpis SSL VPN jest widoczny oraz rozmiar pobranego pliku.

Najwięcej informacji daje porównanie z działającym użytkownikiem referencyjnym z tej samej policy SSL VPN:

Zanotować dokładny czas testu i nazwę użytkownika, którego dotyczy problem.
Sprawdzić, czy opcja pobrania SSL VPN pojawia się w VPN configuration.
Pobrać plik i sprawdzić jego rozmiar w systemie operacyjnym.
Powtórzyć te same czynności dla znanego, działającego użytkownika.
Zapisać, czy błąd dotyczy tylko jednego użytkownika, jednej grupy czy wszystkich użytkowników.

Jeżeli użytkownik referencyjny działa, przyczyny należy szukać raczej w przypisaniu policy, grupie, User ID albo generowaniu certyfikatu konkretnego użytkownika. Jeżeli pobieranie nie działa dla wszystkich, bardziej prawdopodobne stają się wspólny certyfikat SSL VPN, pamięć masowa, pattern, firmware oraz aktywny node w przypadku HA.

Plik .ovpn może zawierać certyfikaty i materiał kluczy. Jego zawartości nie należy umieszczać na zrzutach ekranu, w wiadomościach e-mail ani w zgłoszeniach do pomocy technicznej. Do diagnostyki wystarczą nazwa i rozmiar pliku, czas oraz widoczny komunikat o błędzie.

Jeśli nie działa już dostęp do portalu albo logowanie, błąd występuje przed wygenerowaniem profilu. Należy wtedy sprawdzić Administration > Device access, uwierzytelnianie VPN Portal oraz vpnportal.log lub access_server.log. Pełną konfigurację firewalla opisuje artykuł Konfiguracja SSL VPN Remote Access.

Gdy pliku .ovpn w ogóle nie ma

Firewall wyświetla konfiguracje SSL VPN tylko użytkownikom przypisanym do policy Remote Access SSL VPN. Samo poprawne zalogowanie do portalu nie potwierdza jeszcze tego uprawnienia.

Sprawdzenie policy i członkostwa w grupie

Otworzyć Remote access VPN > SSL VPN.
Edytować oczekiwaną policy.
W sekcji Policy members sprawdzić, czy wpisany jest użytkownik albo jego rzeczywista grupa.
Zweryfikować członkostwo w grupie w Authentication > Users lub Authentication > Groups.
Ponownie zalogować się do VPN Portal jako użytkownik, którego dotyczy problem, i jeszcze raz otworzyć VPN configuration.

Użytkownik może poprawnie zalogować się dzięki innemu uprawnieniu do portalu, a mimo to nie otrzymać konfiguracji SSL VPN. Użytkownicy i grupy typu Guest nie są prawidłowymi Policy members dla Remote Access SSL VPN. Jeśli bezpośredni członkowie będący użytkownikami lub grupami są identyczni, Sophos Firewall podczas zapisywania nowszej policy usuwa ich z wcześniejszej policy. Dlatego należy sprawdzić rzeczywiście pozostałych Policy members oraz nakładające się członkostwa w grupach.

Problem dotyczy tylko nowych lub pojedynczych użytkowników

Warto wtedy dodatkowo sprawdzić wewnętrzny User ID w Authentication > Users > Show additional properties. Sophos Firewall obsługuje identyfikatory użytkowników i grup tylko do 65535. Wyższy identyfikator może uniemożliwiać pobranie; bezpieczną kontrolę i porządkowanie opisuje artykuł Limit User ID w Sophos Firewall.

Potwierdzone poprawne logowanie do VPN Portal przemawia przeciwko limitowi User ID jako głównej przyczynie. Decydujący jest jednak widoczny identyfikator konta, którego dotyczy problem, a nie liczba użytkowników na liście.

Należy też sprawdzić nazwę użytkownika oraz pola Subject certyfikatu i CA pod kątem znaków specjalnych. Sophos zaleca w tej procedurze nazwy użytkowników w ASCII oraz brak znaków UTF-8 w polach certyfikatu lub CA. Nazwa użytkownika jest uwzględniana w nazwie pliku .ovpn i w certyfikacie generowanym dla danego użytkownika. Działający użytkownik testowy z prostą nazwą ASCII pomaga zawęzić przyczynę; nie należy w tym celu spontanicznie zmieniać nazw produkcyjnych tożsamości AD lub Entra.

Gdy pobrany plik ma 0 bajtów lub nie jest generowany

Pusty plik oznacza, że link pobierania istnieje, ale wygenerowanie lub udostępnienie nie dostarczyło użytecznej konfiguracji. Sophos wskazuje niekompletną konfigurację certyfikatu lub CA jako możliwą przyczynę. Przed regenerowaniem czegokolwiek należy zabezpieczyć logi i stan systemu.

Zabezpieczenie logów dokładnie w czasie testu

W Diagnostics > Tools > Troubleshooting logs można pobrać odpowiednie pliki bez ingerowania w Advanced Shell. W zależności od etapu błędu ważne są:

vpnportal.log dla pobierania w VPN Portal;
access_server.log dla zwykłego uwierzytelniania;
oauth_sso_vpn.log w przypadku Microsoft Entra ID SSO;
peruser_cert_sslvpn.log dla generowania certyfikatu konkretnego użytkownika;
vpncertificate.log dla certyfikatów i Certificate Authorities;
sslvpn.log dla usługi SSL VPN.

Logi należy ograniczyć do wcześniej zanotowanego czasu testu i nazwy użytkownika. Jeśli portal i uwierzytelnianie działają, ale peruser_cert_sslvpn.log w tym samym czasie pokazuje błąd, kolejnym właściwym punktem kontroli są certyfikat i CA. Jeśli od czasu upgrade’u lub przełączenia HA błąd dotyczy wszystkich użytkowników, trzeba dodatkowo zapisać wersję firmware, aktywny node i czas zmiany ról. Klasyfikację pozostałych plików wyjaśnia artykuł Usługi i logi Sophos Firewall.

Sprawdzenie pamięci tymczasowej

Pełna partycja tymczasowa również może uniemożliwić wygenerowanie profilu. Po zalogowaniu przez SSH do Sophos Firewall należy otworzyć 5 Device Management > 3 Advanced Shell i odczytać ilość wolnego miejsca:

df -kh /tmp

Istotne są kolumny Avail i Use% dla systemu plików, na którym znajduje się /tmp. Jeśli prawie nie ma wolnego miejsca, nie należy ręcznie usuwać nieznanych plików. Zamiast tego trzeba zabezpieczyć logi i stan systemu oraz ustalić, który proces zajmuje miejsce. Sophos usunął już starszy błąd NC-142397, w którym SSL VPN zapełniał partycję /tmp; identyfikator błędu jest więc wskazówką dotyczącą wersji, ale nie automatyczną diagnozą dla aktualnych buildów.

Sprawdzenie certyfikatu SSL VPN i Signing CA

W Remote access VPN > SSL VPN > SSL VPN global settings pole SSL server certificate pokazuje, którego certyfikatu firewall używa dla tunelu SSL VPN. Nie należy mylić go z certyfikatem HTTPS VPN Portal w Administration > Admin and user settings.

Prawidłowe rozróżnienie okresu ważności certyfikatów publicznych

Zapowiedziane skrócenie ważności publicznie zaufanych certyfikatów TLS nawet do 47 dni nie dotyczy automatycznie certyfikatów X.509 poszczególnych użytkowników osadzonych w pliku .ovpn. Domyślnie podpisuje je wewnętrzny CA SFOS, więc nie należą do publicznej Web PKI. Nie wymaga to comiesięcznego pobierania profilu ani przejścia na publiczny CA.

Certyfikat HTTPS VPN Portal i SSL server certificate tunelu nadal pełnią odrębne role. Certyfikat portalu trzeba odnawiać na czas, ponieważ chroni usługę dostępną przez przeglądarkę; może tu pasować automatycznie odnawiany certyfikat Let’s Encrypt. Zmiana Protocol, SSL server certificate, Override hostname lub Port staje się jednak niezawodnie skuteczna dopiero po ponownym pobraniu i imporcie pliku .ovpn. To rozróżnienie zapobiega niepotrzebnej przebudowie wewnętrznej PKI SSL VPN z powodu krótszych okresów ważności publicznych certyfikatów.

Następnie w Certificates > Certificates oraz Certificates > Certificate authorities należy sprawdzić:

Czy wybrany certyfikat serwera SSL istnieje i jest nadal ważny?
Czy wystawiający go CA istnieje i jest zaufany?
Czy dla certyfikatu zewnętrznego zaimportowano kompletny łańcuch Intermediate CA i Root CA?
Czy czas wystąpienia błędu pokrywa się ze zmianą certyfikatu, restore’em lub migracją?

Domyślnie firewall korzysta z wbudowanego ApplianceCertificate, podpisanego przez Default CA. Wyjaśnia to zwykłą zależność, ale nie dowodzi jeszcze, który obiekt certyfikatu powoduje konkretny błąd. W szczególności błędu w peruser_cert_sslvpn.log nie wolno automatycznie interpretować jako uszkodzonego ApplianceCertificate.

W przypadku pliku o rozmiarze 0 bajtów Sophos zaleca sprawdzenie faktycznie używanego Signing CA oraz odpowiedniego certyfikatu wygenerowanego przez ten CA. Konkretna naprawa zależy jednak od rodzaju certyfikatu:

ApplianceCertificate: Tylko dla tego wbudowanego certyfikatu Sophos dokumentuje czynność Regenerate w Certificates > Certificates. Należy jej użyć tylko wtedy, gdy ApplianceCertificate jest wybrany jako certyfikat serwera SSL, a komunikat w logu lub Sophos Support potwierdził, że to on jest źródłem problemu.
Zewnętrzny certyfikat serwera SSL: Sprawdzić certyfikat, klucz prywatny, Intermediate CA i Root CA jako jeden spójny łańcuch, a w razie jednoznacznego komunikatu o błędzie ponownie zaimportować go w kontrolowany sposób. Nie ma tu uniwersalnego kroku Regenerate.
Certyfikat SSL VPN konkretnego użytkownika: Błąd w peruser_cert_sslvpn.log nie dotyczy automatycznie certyfikatu serwera SSL. Sophos nie opisuje obecnie ogólnej procedury w UI do resetowania tego certyfikatu użytkownika. Dlatego zabezpieczone logi należy przekazać do Sophos Support; nie stosuje się starych instrukcji dla Shell lub bazy danych.

Po jednoznacznym zidentyfikowaniu obiektu naprawę przeprowadza się w kontrolowany sposób:

Utworzyć aktualny backup firewalla.
Udokumentować wybrany certyfikat serwera SSL, wystawiający go CA, konkretny komunikat w logu oraz usługi, które go używają.
Wykonać odpowiednią czynność z jednego z trzech przypadków w oknie serwisowym; jeżeli przypadek nie jest jednoznaczny, eskalować do Sophos Support.
Pobrać nowy plik .ovpn dla użytkownika pilotażowego, zaimportować go i przetestować tunel.
Dopiero po udanym teście pilotażowym rozprowadzić nowe profile do wszystkich użytkowników, których dotyczy problem, i sprawdzić pozostałe usługi, na które zmiana mogła wpłynąć.

⚠️ Nie należy zamiast tego edytować Default CA na podstawie przypuszczeń. Zapisanie powoduje ponowne wygenerowanie tego CA. Może to wpłynąć na znacznie więcej certyfikatów i relacji zaufania niż pojedynczy certyfikat serwera SSL VPN. Artykuł Kontrolowane odnawianie Default CA na Sophos Firewall wyjaśnia inwentaryzację, okno serwisowe, migrację profili i odzyskiwanie.

Sprawdzenie pattern, firmware i HA

W Backup & firmware > Pattern updates automatycznie instalowane komponenty powinny mieć aktualny znacznik czasu i status Success. Jedno ręczne pobranie za pomocą Update pattern now ma sens, gdy widoczny jest błąd pattern; wielokrotne klikanie nie zastępuje diagnostyki. Pełna procedura znajduje się w artykule Konfiguracja i sprawdzanie Pattern Updates.

W ocenie należy też uwzględnić dokładny build firmware. Sophos wymienia NC-149642 — użytkownicy nie mogli pobrać konfiguracji SSL VPN z VPN Portal — wśród rozwiązanych problemów w SFOS 21.0 MR2 Build 349 oraz SFOS 22.0 GA Build 411. Inne starsze poprawki dotyczyły pobierania po upgrade’ach lub przełączeniu HA. Historyczny identyfikator błędu nie dowodzi aktualnej przyczyny, ale pokazuje, dlaczego przed głębszą naprawą należy porównać nieaktualny build z Release Notes. Aktualizację należy zaplanować, a nie improwizować podczas trwającej diagnostyki; służy do tego artykuł Aktualizacja firmware SFOS w Sophos Firewall.

W klastrze HA należy zanotować rolę, aktywny node i czas ostatniego przełączenia. Jeśli błąd występuje dopiero po zmianie ról, trzeba zabezpieczyć logi VPN i HA z node’a, którego dotyczy problem. Nie należy ręcznie naprawiać wewnętrznych katalogów, wpisów bazy danych ani symlinków w /content/sslvpn. Takie ingerencje wraz z zebranymi informacjami o błędzie należy przekazać do Sophos Support.

Gdy plik istnieje, ale jest nieaktualny

Niepusty plik .ovpn może zostać wygenerowany poprawnie, ale przestać odpowiadać aktualnemu stanowi firewalla. Po zmianie Protocol, SSL server certificate, Override hostname lub Port trzeba ponownie pobrać plik i jeszcze raz zaimportować go w kliencie. Jeśli pole Override hostname jest puste, w profilu mogą znajdować się udostępnione adresy interfejsów; także wtedy po zmianie trzeba pobrać nowy profil.

Zmiany Policy members lub Permitted network resources wymagają natomiast zwykle tylko nowego połączenia. Plik provisioningowy .pro automatycznie pobiera dostępną konfigurację; podczas diagnostyki mimo to należy oddzielnie sprawdzić, czy działa ręczne pobieranie .ovpn.

W przypadku Microsoft Entra ID SSO w Authentication > Services wybiera się ten sam serwer Entra ID dla VPN portal authentication methods i SSL VPN authentication methods. Następnie trzeba ponownie pobrać plik .ovpn. Jeśli .pro provisionuje dodatkowo IPsec, sprawdza się też VPN (IPsec/dial-in/L2TP/PPTP) authentication methods z tym samym serwerem. Pełną zależność opisuje artykuł Microsoft Entra ID SSO dla Sophos Connect i VPN Portal.

Weryfikacja wyniku i prawidłowa eskalacja

Błąd można uznać za usunięty dopiero wtedy, gdy ta sama procedura działa w pełni dla zwykłego użytkownika pilotażowego:

Logowanie do VPN Portal kończy się powodzeniem.
Oczekiwany wpis SSL VPN jest widoczny w VPN configuration.
Pobrany plik .ovpn nie jest pusty i nie zawiera komunikatu o błędzie.
Nowy profil można zaimportować w docelowym kliencie.
Tunel zostaje zestawiony i otrzymuje adres z oczekiwanej puli SSL VPN.
Dozwolony cel wewnętrzny działa zarówno przez adres IP, jak i nazwę hosta.
Cel celowo niedozwolony pozostaje zablokowany.

Jeśli generowanie nadal nie działa na aktualnej wersji firmware, pakiet dla pomocy technicznej powinien zawierać co najmniej model, build firmware, rolę HA, czas błędu, użytkownika i grupę, odpowiednią policy, rozmiar pliku, widoczny komunikat o błędzie, ostatnie zmiany oraz wymienione logi. Nie należy przesyłać samego pliku .ovpn. W przypadku, który można odtworzyć, takie dowody są cenniejsze niż ryzykowne zmiany wewnętrznych plików.