Otwieranie ticketu Sophos: przygotowanie i portal

Ticket Sophos szybciej pomaga, gdy najważniejsze informacje są przygotowane już przy jego otwieraniu. W przypadku Sophos Firewall chodzi przede wszystkim o numer seryjny, model, wersję firmware, status licencji, czas błędu, dotkniętą funkcję, logi, zrzuty ekranu i wykonane już kroki kontrolne.

Ten przewodnik opisuje, kiedy Sophos Support Case ma sens, jakie informacje należy przygotować i jak otworzyć ticket w Sophos Support Portal w sposób możliwy do prześledzenia. Do klasyfikacji różnych dostępów Sophos pasuje także artykuł Portale Sophos: SophosID, Central, support i dostępy do firewalla.

Kiedy ticket Sophos ma sens

Ticket Sophos ma sens, gdy problemu nie da się już wyjaśnić lokalnie wyłącznie przez konfigurację, logi lub znane procesy operacyjne.

Typowe przypadki:

• uszkodzenie sprzętu, RMA lub podejrzenie wadliwej appliance
• problem z licencją lub kontem z konkretnym numerem seryjnym
• problem z firmware, hotfixem lub aktualizacją
• powtarzający się crash usługi lub niejasny stan systemu
• problem VPN, WAF, HA, RED lub routingu po własnym wstępnym zawężeniu
• błąd, który po sprawdzeniu logów i reprodukcji wygląda na problem produktu
• zgłoszenie, w którym Sophos potrzebuje dostępu do wewnętrznych danych analitycznych

Przed ticketem należy wykonać oczywiste kontrole lokalne. W Sophos Firewall nie oznacza to, że wszystko musi być już rozwiązane. Im dokładniej opisane są sytuacja wyjściowa, okno czasowe i dotknięta funkcja, tym mniej pytań zwrotnych.

Czego Sophos Support nie zastępuje

Enhanced Support nie jest bezpłatną usługą konfiguracji. Ticket Sophos należy otworzyć wtedy, gdy funkcja firewalla nie działa już prawidłowo albo podejrzewa się konkretny błąd produktu, licencji, sprzętu lub oprogramowania.

Ticket Sophos nie jest właściwy, gdy brakuje tylko wiedzy potrzebnej do pożądanej konfiguracji. Typowe przykłady:

• planowanie nowej topologii VPN
• uporządkowanie reguł firewalla
• konfiguracja NAT lub WAF dla nowej usługi
• sprawdzenie projektu HA
• ocena koncepcji routingu lub architektury VLAN
• przebudowa istniejącej konfiguracji według best practices

W takich przypadkach lepszym kontaktem jest Avanet Support. Firewall można wtedy sprawdzić, zaplanować lub skonfigurować zgodnie z wymaganiami w ramach warunków supportu Avanet. Sophos Support pomaga przede wszystkim w technicznych przypadkach produktowych, w których funkcja mimo poprawnej konfiguracji nie działa albo problem dotyczy appliance, licencji lub przypisania cloud.

Enhanced Support, Incident Levels i czasy docelowe

Enhanced Support poprawia uprawnienie do wsparcia i cele reakcji, ale nie zastępuje dobrego opisu problemu. Czasy docelowe są celami odpowiedzi, a nie gwarantowanymi czasami rozwiązania. Złożony problem VPN, HA lub routingu może potrwać dłużej mimo szybkiej pierwszej odpowiedzi, jeśli brakuje logów, reprodukcji lub dostępu zdalnego.

Poniższe wartości służą jako orientacja dla Enhanced Support:

• P1: całkowita awaria produkcyjna lub poważny incydent bezpieczeństwa bez praktycznego workaroundu. 30 minut
• P2: silny wpływ produkcyjny, kilku użytkowników lub krytyczne usługi dotknięte. 2 godziny
• P3: problem techniczny o ograniczonym wpływie albo z istniejącym workaroundem. 4 godziny
• P4: niewielki wpływ, ogólne pytanie techniczne lub problem niekrytyczny czasowo. 24 godziny

Sophos stosuje dodatkowo poziomy Severity w procesie supportu. W zależności od regionu, uprawnienia do wsparcia i typu sprawy te nazwy i wartości docelowe mogą być w portalu pokazane inaczej:

• Critical: poważna awaria produkcyjna, brak workaroundu, konieczna natychmiastowa obsługa. 4 godziny, z obsługą 24/7 tam, gdzie dostępna
• High: istotne ograniczenie systemów produkcyjnych. 8 godzin roboczych
• Medium: ograniczona funkcja, możliwy workaround lub ograniczony wpływ. 24 godziny robocze
• Low: niewielki wpływ, ogólne pytanie lub temat planowania. 24 godziny robocze

Severity należy wybierać uczciwie według rzeczywistego wpływu. Zbyt wysoka klasyfikacja bez odpowiedniego impactu rzadko pomaga, bo Sophos zapyta w tickecie o wpływ, odtwarzalność i dotknięte usługi. Jeśli sprawa jest krytyczna biznesowo, opis powinien to jasno wykazać: dotknięte lokalizacje, liczba użytkowników, brak workaroundu, czas, status redundancji i już sprawdzone działania.

Wymagania

Do technicznego ticketu supportowego zwykle potrzebne są:

• SophosID do Support Portal
• ważna licencja lub aktywne uprawnienie do wsparcia
• dotknięty numer seryjny albo przypisanie konta
• w przypadkach partnerskich: przypisanie klienta i odpowiednia licencja lub numer seryjny
• produkt i model, na przykład Sophos Firewall XGS albo firewall wirtualny
• wersja firmware i build
• krótki opis błędu z wpływem
• okno czasowe problemu ze strefą czasową
• dostępne logi, zrzuty ekranu lub komunikaty błędów

Sophos sprawdza w sprawach supportowych przypisanie licencji i numeru seryjnego. Bez pasującej licencji lub numeru seryjnego case może trafić do Customer Care do walidacji. To opóźnia obsługę techniczną. Jeśli partner otwiera case dla klienta, przypisanie klienta i dotknięta licencja lub numer seryjny również muszą być podane jasno. Jeśli Avanet ma zarządzać sprawami supportowymi w imieniu klienta, klient musi przyznać Avanet odpowiedni dostęp partnerski.

Numer seryjny firewalla znajduje się bezpośrednio w dashboardzie SFOS. Procedura jest opisana w Znajdowanie numeru seryjnego Sophos Firewall.

Jeśli zgłoszenie dotyczy uszkodzenia sprzętu, należy dodatkowo sprawdzić artykuł Co zrobić w przypadku technicznej usterki sprzętu Sophos?.

Klasyfikacja kanałów supportu

Sophos oferuje kilka dróg do supportu. Nie każda droga jest tak samo dobra do tego samego celu.

• Sophos Support Portal: możliwe do śledzenia techniczne Support Cases, załączniki, RMA, dłuższa analiza
• Telefon: pilne dopytanie z istniejącym numerem ticketu lub kontakt przy problemach z dostępem
• Digital Chat: szybka orientacja, pytania o portal lub ogólne pytania supportowe
• Sophos Community: pytania niepoufne, znane objawy, wymiana z innymi administratorami
• Sophos TechVids i Docs: tematy how-to, konfiguracja i znane procedury

Dla technicznych spraw firewallowych Support Portal jest najczęściej najlepszym wejściem, ponieważ numer ticketu, historia i załączniki pozostają tam możliwe do prześledzenia. Telefon lub chat są szczególnie przydatne, gdy istniejący ticket trzeba pilnie priorytetyzować albo wyjaśnić problem z portalem.

Aktualne kanały kontaktu i numery telefonów są na oficjalnej stronie Sophos Support contact. Ogólny przegląd supportu pozostaje dostępny pod Sophos Support.

Przygotowanie konta i dostępu partnera

Do Support Portal wymagany jest SophosID. Konto powinno pasować do firmy, licencji lub tenanta Sophos Central, aby dotknięte produkty były widoczne. Jeśli firewall jest obsługiwany przez partnera, przed właściwą sprawą supportową należy wyjaśnić, czy partner może zarządzać cases.

Jeśli Avanet ma towarzyszyć case w imieniu klienta albo komunikować się z Sophos, dostęp do przypisania klienta w Sophos Support Portal musi być dozwolony. Sophos opisuje ten krok pod Allow a Sophos Partner to manage your account.

Praktycznie oznacza to:

1. Sprawdzić SophosID.
2. Przygotować dotkniętą licencję lub numer seryjny.
3. Jeśli Avanet ma pomagać, przygotować dostęp partnerski w portalu Sophos.
4. Jeśli Sophos potrzebuje dostępu zdalnego, przygotować Support Access na firewallu.

Przygotowanie przed ticketem

Support Case powinien być sformułowany tak, aby support mógł zaklasyfikować problem bez zgadywania.

Dane techniczne

Dla Sophos Firewall powinny być gotowe:

• numer seryjny
• model lub platforma
• wersja firmware i build
• status licencji lub plan supportu, jeśli istotny
• status HA, jeśli firewall jest częścią klastra
• dotknięta funkcja, na przykład IPsec, SSL VPN, WAF, RED, Web Protection lub Reporting
• dokładna godzina błędu ze strefą czasową
• dotknięci użytkownicy, sieci, lokalizacje lub usługi
• ostatnie zmiany przed problemem

W klastrach HA oba węzły powinny być jednoznacznie udokumentowane. Do klasyfikacji ról, numerów seryjnych i pracy HA pasuje Warianty i eksploatacja klastra HA Sophos Firewall.

Reprodukcja i wpływ

Opis nie powinien mówić tylko, że coś nie działa. Lepszy jest krótki, możliwy do sprawdzenia opis:

• Czego oczekiwano?
• Co dzieje się zamiast tego?
• Od kiedy problem występuje?
• Czy problem jest stały czy sporadyczny?
• Jak można go odtworzyć?
• Którzy użytkownicy lub usługi są dotknięte?
• Czy istnieje workaround?
• Jak krytyczny jest wpływ na działanie?

Jeśli ticket składa się tylko ze zrzutu ekranu i jednego zdania, support niemal na pewno będzie musiał dopytywać. To kosztuje czas, szczególnie przy problemach VPN, routingu lub HA.

Logi i załączniki

W problemach firewallowych logi są często ważniejsze niż długie przypuszczenia. Jeśli problem da się odtworzyć, należy możliwie dokładnie zapisać okno błędu, a następnie zabezpieczyć odpowiednie logi.

W zależności od problemu pomocne są:

• zrzut ekranu komunikatu błędu
• zrzut Log Viewer z filtrem
• właściwe logi usług
• Packet Capture lub tcpdump, jeśli przepływ pakietów jest niejasny
• zrzut firmware lub licencji
• krótki schemat sieci albo dotknięte adresy IP, jeśli dotyczy routingu
• opis już sprawdzonych reguł, obiektów NAT lub parametrów VPN

Dla pełnych archiwów logów właściwą procedurą jest Zabezpieczanie logów Sophos Firewall do supportu i analizy. Który plik logu należy do którego modułu, podsumowuje Prawidłowe przypisanie logów usług Sophos Firewall.

Nie każdy załącznik odpowiada na to samo pytanie:

• Która reguła lub moduł podjął decyzję?: eksport Log Viewer, Rule ID, NAT ID, dotknięty okres
• Która usługa zgłasza błędy?: odpowiednie logi usług lub pełne archiwum /log
• Czy ruch dociera i przechodzi dalej?: Packet Capture w WebAdmin
• Czy support potrzebuje pliku PCAP?: wąski zrzut tcpdump, oddzielnie od archiwum logów
• Czy zmiana wywołała problem?: audit trail, czas zmiany, dotknięte obiekty

Szerokie archiwum logów bez czasu błędu jest często mniej pomocne niż mniejszy pakiet danych z dokładną godziną, jasną reprodukcją i odpowiednim zrzutem. Przy problemach przepływu pakietów plik PCAP powinien być traktowany oddzielnie od archiwum logów, aby w tickecie było jasne, który plik zawiera logi usług, a który pakiety sieciowe.

⚠️ Logi, zrzuty ekranu i Packet Captures mogą zawierać wewnętrzne adresy IP, publiczne IP, nazwy użytkowników, nazwy hostów, szczegóły certyfikatów lub inne informacje poufne. Przed przesłaniem musi być jasne, kto otrzyma dane i czy trzeba je wcześniej oczyścić.

Consolidated Troubleshooting Report

Przy problemach z urządzeniem lub systemem Sophos może zażądać Consolidated Troubleshooting Report. W firewallu znajduje się on pod Diagnostics > Tools. Raport zbiera informacje diagnostyczne i odpowiednie dane logów w skompresowanym archiwum.

Taki raport jest szczególnie pomocny przy:

• crashach usług
• niejasnych stanach systemu
• powtarzających się błędach po aktualizacjach
• problemach, których Sophos nie może ocenić tylko na podstawie zrzutu ekranu
• sprawach supportowych, w których może być dotkniętych kilka modułów

Raport nie zastępuje jednak dobrego opisu błędu. Godzina, strefa czasowa, dotknięta funkcja i kroki reprodukcji muszą nadal znaleźć się w tickecie.

Support Access i Remote Assistance ID

W sprawach firewallowych Sophos może poprosić o Remote Assistance ID albo o aktywny Support Access. Dzięki temu Sophos może uzyskać czasowo ograniczony dostęp do firewalla, jeśli jest to potrzebne do analizy.

Support Access należy aktywować tylko wtedy, gdy jest potrzebny w konkretnym przypadku. Po zamknięciu sprawy dostęp należy ponownie wyłączyć albo przynajmniej sprawdzić. Praktyczną procedurę opisuje Udostępnienie Sophos Firewall Support Access dla Avanet. Oficjalna dokumentacja Sophos opisuje ogólny proces pod Support access.

W tickecie należy podać:

• czy Support Access jest już aktywny
• Remote Assistance ID, jeśli istnieje
• na jak długo dostęp został włączony
• czy MFA lub reguły ACL wpływają na dostęp
• czy istnieje okno serwisowe na testy

Otwieranie ticketu w Sophos Support Portal

Sophos Support Portal jest dostępny tutaj:

➜ Sophos Support Portal

Zalogować się SophosID. W zależności od wersji portalu interfejs może wyglądać nieco inaczej, ale podstawowa idea pozostaje taka sama: utworzyć nowy Technical Support Case, wybrać produkt, opisać problem i przesłać załączniki.

Proces zwykle wygląda tak:

1. Zalogować się do Support Portal.
2. Otworzyć Support Cases.
3. Utworzyć nowy Technical Support Case.
4. Wybrać account, kontakt, Severity, temat i kategorię produktu.
5. Opisać problem i wpływ.
6. Odpowiedzieć na pytania specyficzne dla produktu.
7. Podać numer seryjny lub numer licencji.
8. Dołączyć logi, zrzuty ekranu, CTR lub pliki PCAP.
9. Wysłać case i udokumentować numer ticketu wewnętrznie.

W formularzu problem powinien być opisany krótko, ale kompletnie. Ważny jest sensowny temat. Temat taki jak IPsec VPN fails after SFOS 22.0 MR1 upgrade on XGS 2100 jest znacznie lepszy niż VPN problem.

Jeśli na pole nie da się odpowiedzieć, Not Applicable jest często lepsze niż puste pole. Puste pola obowiązkowe szybko prowadzą do pytań albo opóźniają przypisanie.

Co powinno znaleźć się w opisie

Dobry opis jest wystarczająco krótki do przeczytania i wystarczająco konkretny do pracy.

Praktyczny szablon:

Product:
Serial number:
License number:
Model:
Firmware version:
Support plan:
Impact:
Start time and time zone:
Affected users/sites/services:
Recent changes:
Expected behavior:
Actual behavior:
Steps to reproduce:
Checks already performed:
Remote Assistance ID:
Attachments:

Przy problemach z regułami firewalla, NAT lub VPN należy dodatkowo podać:

• sieci source i destination
• dotkniętą usługę lub port
• oczekiwaną regułę firewalla
• regułę NAT, jeśli dotyczy
• tunel VPN lub profil Remote Access
• wynik Log Viewer
• Packet Capture lub tcpdump PCAP, jeśli przepływ pakietów jest istotny
• Support Access ID, jeśli Sophos potrzebuje dostępu zdalnego

Przy analizie reguł Test reguły firewalla z Log Viewer, Policy Test i Packet Capture może pomóc przed otwarciem Support Case.

RMA i uszkodzenie sprzętu

Przy uszkodzeniach sprzętu Sophos potrzebuje dodatkowych informacji do obsługi RMA. Obejmuje to nie tylko opis błędu i numer seryjny, lecz także model, rewizję, firmware, licencję, status HA i dane wysyłkowe.

Należy przygotować:

• uszkodzony produkt i model
• numer seryjny dotkniętego urządzenia
• wersję firmware
• numer licencji lub przypisanie licencji
• opis objawów i już sprawdzone punkty
• Dead on arrival, jeśli urządzenie było dotknięte bezpośrednio po dostawie
• klaster HA: tak lub nie
• adres dostawy i osobę kontaktową
• numer telefonu i adres e-mail
• szczególne wskazówki wysyłkowe

Przy firewallach należy dodatkowo sprawdzić, czy istnieje aktualny backup i jak zostanie odtworzony firewall zastępczy. Dla backupu i restore pasuje Backup i restore na Sophos Firewall.

W przypadkach RMA należy kierować się aktualnym Sophos Support Portal i odpowiedzią w tickecie. Wpisy community lub starsze opisy procedur mogą wyglądać pomocnie, ale nie są decydujące, jeśli Sophos w konkretnej sprawie wymaga innych danych.

Dopytywanie i eskalacja

Po otwarciu powinna przyjść e-mailem potwierdzenie z numerem ticketu. Ten numer ticketu należy podawać w każdej późniejszej komunikacji.

Jeśli krytyczna sprawa nie postępuje wystarczająco szybko, nie należy otwierać drugiego ticketu. Duplikaty powodują więcej koordynacji i mogą raczej spowolnić obsługę.

Lepiej:

1. mieć gotowy istniejący numer ticketu
2. konkretnie opisać impact i pilność
3. dosłać brakujące logi lub odpowiedzi
4. dopytać telefonicznie lub przez Digital Chat z numerem ticketu
5. eskalować w istniejącym case, jeśli wartość docelowa nie została dotrzymana
6. wewnętrznie udokumentować, kto przekazał jaką odpowiedź

Eskalacja powinna być uzasadniona. Sensowne powody to na przykład:

• przekroczono docelowy czas odpowiedzi.
• awaria produkcyjna trwa nadal.
• brak reakcji mimo dosłanych informacji.
• błędne przypisanie lub niepasująca kategoria produktu.
• case blokuje planowany proces odtworzenia lub konserwacji.

Eskalacja powinna zawsze opisywać aktualny wpływ biznesowy. Zdanie We need an update jest słabsze niż konkretna informacja The main site-to-site VPN between headquarters and production is still down, 80 users cannot access ERP, no workaround is available.

Przy poważnych przypadkach bezpieczeństwa lub awarii należy dodatkowo sprawdzić, czy mają zastosowanie inne procesy supportu lub incident response. Zwykły ticket techniczny nie jest automatycznie pełnym procesem incident response.

Checklista

• SophosID działa.
• Licencja i uprawnienie do supportu są wyjaśnione.
• Numer seryjny, model i wersja firmware są udokumentowane.
• Znany jest czas błędu ze strefą czasową.
• Opisano wpływ na użytkowników, usługi lub lokalizację.
• Ostatnie zmiany zostały zanotowane.
• Reprodukcja lub objaw są zrozumiałe.
• Odpowiednie logi i zrzuty ekranu są przygotowane.
• Packet Capture lub tcpdump PCAP jest przygotowany tylko dla problemów przepływu pakietów.
• Dane poufne w załącznikach zostały sprawdzone.
• Przy RMA: dane wysyłkowe i status HA są przygotowane.
• Numer ticketu jest dokumentowany wewnętrznie.

FAQ