Sophos Firewall: routing SD-WAN dla Reply Packets i System Traffic

Trasy SD-WAN w Sophos Firewall mają znaczenie nie tylko dla klasycznego ruchu klient-internet. W zależności od środowiska mogą obejmować także Reply Packets i ruch generowany przez system. To właśnie w tych przypadkach często pojawiają się trudne do wykrycia problemy z routingiem: reguła wygląda poprawnie, Gateway jest aktywny, ale odpowiedzi wracają niewłaściwą ścieżką albo sama zapora nie dociera do usługi przez oczekiwane łącze.

Ten przewodnik wyjaśnia dwie opcje CLI, reply-packet i system-generate-traffic, wskazuje, kiedy należy je sprawdzić, oraz pokazuje, jak bezpiecznie testować zmiany. Przy standardowej konfiguracji trasy SD-WAN warto zacząć od artykułu Konfiguracja i testowanie trasy SD-WAN w Sophos Firewall. Ogólną kolejność tras statycznych, SD-WAN Policy Routes i tras VPN opisuje także artykuł Bezpieczna zmiana Route Precedence w Sophos Firewall.

⚠️ Te ustawienia mogą natychmiast wpłynąć na routing produkcyjny. Przed zmianą należy udokumentować bieżący stan, wybrać okno serwisowe i przygotować jednoznaczną drogę powrotu. Szczególnie ryzykowne są szerokie trasy SD-WAN z Any, Route Precedence ustawione przed Static Routes oraz aktywny routing SD-WAN dla System Traffic lub Reply Packets.

Podstawy i ograniczenia

Do czego służą obie opcje

W przypadku tras SD-WAN trzeba rozróżnić zwykły ruch przekazywany, pakiety odpowiedzi oraz ruch generowany przez samą zaporę. Obie opcje nie określają, czy konkretna trasa SD-WAN jest skonfigurowana poprawnie. Rozszerzają natomiast zakres typów ruchu, które mogą zostać uwzględnione przez SD-WAN Policy Routing.

Opcje pełnią różne funkcje:

• reply-packet: Dotyczy pakietów odpowiedzi należących do istniejącego ruchu. Pozwala wpływać przez SD-WAN na drogę powrotną w określonych scenariuszach poza WAN.
• system-generate-traffic: Dotyczy ruchu generowanego przez samą zaporę. Umożliwia kierowanie połączeń zapory przez zdefiniowane trasy SD-WAN.

Nie należy włączać obu opcji bez analizy tylko dlatego, że „SD-WAN nie działa”. Najpierw trzeba ustalić, czy problem rzeczywiście dotyczy Reply Packets lub ruchu generowanego przez system. W przypadku zwykłych połączeń faktyczną przyczyną często jest Firewall Rule, NAT, Route Precedence, status Gateway albo zbyt szeroka trasa SD-WAN.

Reply Packets

Reply Packets to pakiety odpowiedzi należące do istniejącego ruchu. Sophos Firewall zasadniczo wymusza dla takich odpowiedzi routing symetryczny na interfejsach WAN: pakiety odpowiedzi powinny wracać przez ten sam interfejs WAN, przez który nadeszło pierwotne połączenie.

Opcja reply-packet ma znaczenie przede wszystkim wtedy, gdy pakiety odpowiedzi w określonych scenariuszach mają być uwzględniane przez SD-WAN Policy Routing. Typowym przykładem jest routing asymetryczny na interfejsach innych niż WAN, na przykład między LAN i DMZ.

Istotne ograniczenie: jeśli pierwotny ruch przechodzi przez Default Route lub WAN Link Load Balancing, trasy SD-WAN nie mają zastosowania do tych Reply Packets. Zapora nadal korzysta wtedy z właściwej drogi powrotnej przez interfejs pierwotnego połączenia.

Typowe pytania kontrolne:

• Czy jest to rzeczywiście ruch odpowiedzi, a nie nowe połączenie?
• Czy ruch przechodzi przez WAN, LAN, DMZ, XFRM lub inną strefę?
• Czy istnieje trasa SD-WAN, która ma celowo wpływać na drogę powrotną?
• Czy trasa jest zbyt szeroka, na przykład ma Destination Any?
• Czy Route Precedence powoduje dopasowanie przed trasą statyczną lub trasą VPN?

Ruch generowany przez system

Ruch generowany przez system to ruch tworzony przez samą Sophos Firewall. Przykładami są zapytania DNS, pobieranie sygnatur i żądania uwierzytelnienia. W przypadku usług takich jak DHCP, SNMP lub Syslog klasyfikacja zależy od roli i kierunku ruchu; nie każdy ruch kierowany do usługi zapory jest wychodzącym połączeniem generowanym przez system. Domyślnie zapora wysyła własny ruch przez bramy WAN skonfigurowane w Network > WAN link manager.

Dla tego ruchu wartości Incoming interface i Source networks nie są znane, dlatego nie są odpowiednimi selektorami. W trasie SD-WAN przeznaczonej dla ruchu zapory należy więc precyzyjnie ograniczać wyłącznie Destination networks i Services, a pozostałe kryteria pozostawić szerokie. Trasa z Destination Any może w przeciwnym razie nieoczekiwanie skierować ruch systemowy i administracyjny na niewłaściwą ścieżkę.

Zwykła reguła zapory nie jest tu wymagana. Dlatego w Current activities > Live connections ruch generowany przez system ma Firewall Rule ID 0. Local service ACL w Administration > Device access jest od tego niezależna: steruje dostępem do lokalnych usług zapory, a nie wyborem wychodzącej ścieżki SD-WAN. Jeśli potrzebny jest określony Source IP, zwykła reguła SNAT również nie wystarczy: reguły NAT tłumaczą ruch przekazywany, natomiast dla ruchu zapory, zależnie od scenariusza, wymagane jest sys-traffic-nat w Device Console.

Obowiązują również dwa praktyczne ograniczenia:

• Jeśli wszystkie skonfigurowane Gateway w Network > WAN link manager są oznaczone tylko jako Backup, zapora nie przekazuje przez nie ruchu generowanego przez system. Co najmniej jeden Gateway musi mieć status Active.
• Generowany przez system ruch RED na UDP 3410 jest ruchem warstwy 2. Trasy SD-WAN nie mają do niego zastosowania.

Dostęp do serwera uwierzytelniania przez route-based IPsec

Ważnym przypadkiem szczególnym jest serwer AD lub LDAP w centrali, do którego sama zapora oddziału musi uzyskać dostęp przez tunel route-based IPsec. Zwykła reguła LAN do VPN nie steruje tym żądaniem, ponieważ ruch generuje zapora. W tunelu any-to-any z adresowanymi interfejsami XFRM należy więc świadomie zaplanować ścieżkę w obu kierunkach.

W poniższym przykładzie 10.10.1.1 jest widocznym adresem źródłowym zapory oddziału, 10.10.2.15 serwerem AD, a TCP 636 usługą LDAPS. Wartości te nie są ustawieniami domyślnymi produktu. Należy je zastąpić adresem oddziału dozwolonym w tunelu i posiadającym trasę zwrotną w centrali, rzeczywistym serwerem oraz faktycznie skonfigurowaną usługą uwierzytelniania.

1. Na zaporze oddziału utworzyć precyzyjną trasę SD-WAN z Source networks ustawionym na Any, hostem AD jako Destination networks i wymaganą usługą uwierzytelniania. TCP 636 jest właściwe tylko wtedy, gdy serwer rzeczywiście używa LDAPS. Jako Primary Gateway wykorzystać zdalny adres XFRM przez lokalny interfejs XFRM.
2. Włączyć Route only through specified gateways tylko wtedy, gdy żądanie ma być świadomie odrzucane w razie niedostępności tunelu. Sprawdzić przełącznik ruchu generowanego przez system zgodnie z wcześniejszym opisem i włączyć go w kontrolowany sposób dla tej procedury.
3. W Device Console najpierw użyć show advanced-firewall, aby zapisać istniejące wpisy sys-traffic-nat i ich kolejność. Następnie za pomocą translacji źródłowej przypisać własnemu adresowi zapory zaplanowany adres oddziału. Adres ten musi odpowiadać regułom tunelu i ścieżki zwrotnej:

set advanced-firewall sys-traffic-nat add destination 10.10.2.15 snatip 10.10.1.1

4. Na zaporze centrali utworzyć zwrotną trasę SD-WAN od hosta AD do adresu oddziału używanego po translacji, prowadzącą przez zdalny adres XFRM. Source, Destination i Service pozostają równie precyzyjne jak po stronie oddziału.
5. W centrali utworzyć logowane reguły z VPN do sieci serwera oraz z sieci serwera z powrotem do VPN, używając konkretnych hostów i usług. Szerokie przykłady z Any w instrukcjach produktu nie nadają się jako konfiguracja stała.
6. Ping/Ping6 w Administration > Device access dla strefy VPN jest potrzebny tylko wtedy, gdy Probe target jest lokalnym adresem zapory lub XFRM. W przypadku hosta za tunelem, do którego ruch jest przekazywany, potrzebne są zamiast tego odpowiedni tunel, trasa i ewentualnie reguła zapory. Po teście należy przywrócić tymczasowe zezwolenie w Device access do wcześniejszego stanu.

W ramach odbioru należy wykonać rzeczywisty test połączenia z serwerem i logowanie użytkownika. Na zaporze oddziału ruch generowany przez system pojawia się w Current activities > Live connections z Firewall Rule ID 0; w centrali muszą pasować oczekiwane logowane reguły. Packet Capture musi pokazać żądanie i odpowiedź na zaplanowanych interfejsach XFRM. Sam udany ping nie potwierdza ani LDAPS, ani uwierzytelniania i ścieżki zwrotnej.

Podczas rollbacku należy najpierw sprawdzić, czy dwie trasy SD-WAN, reguły, obiekty Gateway i tymczasowe zezwolenie na Ping/Ping6 nie mają innych zależności. Wpis NAT należy usunąć z użyciem dokładnie tych samych selektorów. Jeśli podczas jego tworzenia użyto również netmask lub interface, trzeba je także uwzględnić w poleceniu usuwania:

set advanced-firewall sys-traffic-nat delete destination 10.10.2.15 snatip 10.10.1.1

Następnie za pomocą show advanced-firewall należy sprawdzić, czy zniknął tylko zamierzony wpis. Później należy usunąć wyłącznie trasy, reguły i obiekty utworzone dla tej procedury, przywrócić udokumentowane wcześniejsze wartości obu globalnych przełączników SD-WAN oraz Route Precedence i ponownie przetestować pierwotną ścieżkę danych.

Przygotowanie

Kiedy należy sprawdzić te ustawienia

Obie opcje mają znaczenie przede wszystkim w bardziej złożonych projektach routingu. W prostych środowiskach z jednym WAN rzadko powinny być pierwszym elementem do zmiany.

Uzasadnione powody do weryfikacji:

• Ruch generowany przez zaporę nie korzysta z oczekiwanej ścieżki WAN lub VPN.
• Syslog, Central, DNS, NTP lub Monitoring ma przechodzić przez określone łącze.
• Route-based IPsec VPN z interfejsami XFRM jest używany razem z trasami SD-WAN.
• VoIP lub inny wrażliwy ruch przez SD-WAN/VPN działa tylko w jednym kierunku.
• Packet Capture pokazuje odpowiedzi na innym interfejsie niż oczekiwany.
• Po aktualizacji SD-WAN, IPsec lub NAT zachowuje się inaczej niż wcześniej.
• Szeroka trasa SD-WAN nagle wpływa na sieci wewnętrzne lub dostęp administracyjny.

W scenariuszach IPsec warto dodatkowo skorzystać z artykułu Rozwiązywanie problemów z IPsec VPN w Sophos Firewall. W przypadku pojedynczego połączenia lepszym punktem wyjścia jest często Testowanie reguły Sophos Firewall za pomocą Log Viewer i Packet Capture.

Wyświetlanie bieżącego stanu

Polecenia wykonuje się w Device Console, a nie w Advanced Shell. Jeśli sposób dostępu do konsoli nie jest jeszcze znany, pomocny będzie artykuł Łączenie z Sophos Firewall przez SSH.

Sprawdzenie statusu dla Reply Packets:

show routing sd-wan-policy-route reply-packet

Sprawdzenie statusu dla ruchu generowanego przez system:

show routing sd-wan-policy-route system-generate-traffic

Dodatkowo WebAdmin w Routing > SD-WAN routes, w podpowiedzi dotyczącej informacji o routingu, pokazuje, czy routing SD-WAN jest aktywny dla ruchu generowanego przez system i Reply Packets.

Należy także udokumentować bieżące Route Precedence:

system route_precedence show

Przed każdą zmianą należy zapisać aktualne wyniki poleceń. Jest to ważne, ponieważ późniejszy rollback można przeprowadzić poprawnie tylko wtedy, gdy znany jest wcześniejszy stan.

W Routing > SD-WAN routes należy również ustalić, jak każda trasa objęta zmianą reaguje na awarię bramy. Po włączeniu Route only through specified gateways zapora odrzuca ruch, jeśli wskazane bramy są niedostępne. Bez tej opcji sprawdza kolejne trasy SD-WAN, a następnie WAN Link Load Balancing. Usunięcie wybranego Primary Gateway lub SD-WAN Profile powoduje, że SFOS usuwa również trasę. Jeśli usunięty zostanie tylko Backup Gateway, trasa pozostaje z wartością None jako Backup.

Zmiana konfiguracji

Włączanie i wyłączanie opcji

Włączenie routingu SD-WAN dla Reply Packets:

set routing sd-wan-policy-route reply-packet enable

Włączenie routingu SD-WAN dla ruchu generowanego przez system:

set routing sd-wan-policy-route system-generate-traffic enable

Następnie należy ponownie wykonać polecenia sprawdzające status i udokumentować ich wynik.

Do selektywnego wyłączenia służą polecenia odwrotne:

set routing sd-wan-policy-route reply-packet disable
set routing sd-wan-policy-route system-generate-traffic disable

⚠️ Nie należy wykonywać kilku zmian routingu jednocześnie. Jeśli Route Precedence, trasa SD-WAN, reguła NAT i te opcje CLI zostaną zmienione równocześnie, późniejsze jednoznaczne ustalenie przyczyny błędu będzie bardzo trudne.

Bezpieczny przebieg zmiany

Pragmatyczna procedura ogranicza ryzyko:

1. Dokładnie zdefiniuj analizowany ruch: Source, Destination, Service, Zone i oczekiwany Gateway.
2. Udokumentuj istniejące trasy SD-WAN, Gateway oraz Route Precedence.
3. Sprawdź, czy Destination Any jest rzeczywiście potrzebne.
4. Udokumentuj bieżący stan reply-packet i system-generate-traffic.
5. Zmień tylko jedną opcję.
6. Przeprowadź test na jednoznacznym przykładzie ruchu.
7. Sprawdź Log Viewer, Packet Capture oraz liczniki OUT/IN trasy SD-WAN.
8. Udokumentuj wynik i dopiero potem wprowadzaj kolejne zmiany.

Jeśli zmiana może wpłynąć na dostęp administracyjny, należy przygotować drugą możliwość dostępu: lokalną konsolę, inną wewnętrzną ścieżkę dostępu lub połączenie z nieobjętej zmianą sieci administracyjnej.

Walidacja po zmianie

Po włączeniu opcji zielony status Gateway nie wystarcza. Trzeba sprawdzić, czy oczekiwany ruch rzeczywiście korzysta z właściwej ścieżki.

Live Connections, Log Viewer i liczniki SD-WAN

Przed testem należy sprawdzić w System services > Log settings, czy logowanie SD-WAN jest aktywne. Wpisy pojawiają się w module SD-WAN w Log viewer; dla ruchu przekazywanego na odpowiedniej Firewall Rule musi być dodatkowo aktywne Log firewall traffic. Należy zapisać wcześniejszy stan logowania i przywrócić go po teście, jeśli logowanie włączono tylko tymczasowo.

Ruch generowany przez system nie jest sterowany przez regułę zapory. Można go rozpoznać w Current activities > Live connections po Firewall Rule ID 0 oraz interfejsach Inbound i Outbound. Local service ACL pozostaje niezależnym mechanizmem kontroli dostępu do lokalnych usług zapory.

Należy sprawdzić:

• Czy jest to ruch przekazywany z Firewall Rule ID, czy System Traffic z ID 0?
• Jaki NAT Rule ID jest używany dla ruchu przekazywanego?
• Jaki Gateway lub interfejs pojawia się w logu?
• Czy występują Drops, naruszenia Policy lub nieoczekiwane decyzje Security Feature?
• Czy trasa SD-WAN pokazuje tylko OUT dla Requests, czy również IN dla Replies? Liczniki pojawiają się tylko wtedy, gdy kryteria Source i Destination pasują do danego kierunku.

Packet Capture

Rzeczywisty przepływ pakietów można sprawdzić w Diagnostics > Packet capture. Przy analizie routingu filtr powinien być precyzyjny: Source IP, Destination IP, Port i Protocol.

Istotne jest porównanie:

• Czy pakiet dociera przez oczekiwany interfejs?
• Czy opuszcza zaporę przez oczekiwany interfejs?
• Czy odpowiedź wraca?
• Czy stosowany jest NAT?
• Czy droga powrotna dla Reply Packets jest logiczna?
• Czy Status pokazuje Generated dla żądań generowanych przez zaporę oraz, w odpowiednich przypadkach, Consumed dla odpowiedzi dostarczonych do zapory?
• Czy Gateway ID, NAT ID oraz interfejsy Inbound i Outbound odpowiadają zaplanowanej ścieżce?

Obsługę i interpretację opisuje artykuł Korzystanie z Packet Capture w WebAdmin Sophos Firewall.

Sprawdzanie konkretnej usługi systemowej

Samo dopasowanie trasy nie dowodzi, że usługa działa. Przed testem należy zapisać Destination IP, port, oczekiwany Source IP i oczekiwany interfejs Outbound. Następnie trzeba wywołać dokładnie badaną funkcję, na przykład żądanie uwierzytelnienia lub wyszukiwanie DNS wykonane przez zaporę, i sprawdzić zarówno Packet Capture, jak i potwierdzenie po stronie docelowej. Niedopasowany cel lub inna usługa powinny posłużyć jako test negatywny; precyzyjna trasa nie może dopasować takiego ruchu.

Jeśli ruch generowany przez system nie jest widoczny, należy sprawdzić, czy trasa nie wymaga niepotrzebnie kryteriów Source networks, Incoming interface, User lub Application. Dla ruchu generowanego przez zaporę decydujące powinny być przede wszystkim Destination networks i Services. Jeśli system docelowy oczekuje określonego adresu źródłowego, należy dodatkowo sprawdzić Source IP i ewentualną konfigurację sys-traffic-nat.

Błędy i zależności

Typowe błędy

• Trasa SD-WAN z Destination Any dla ścieżek wewnętrznych: Ruch wewnętrzny lub dostęp administracyjny może zostać skierowany przez WAN. Lepsze są grupy celów internetowych lub konkretne sieci docelowe.
• Route Precedence ustawia SD-WAN przed Static: Bezpośrednio podłączone lub statyczne sieci mogą zostać nieoczekiwanie dopasowane przez SD-WAN. Należy sprawdzić Route Precedence i w razie potrzeby ustawić Static przed SD-WAN.
• Aktywne system-generate-traffic bez ograniczenia celu: Usługi zapory mogą korzystać z niewłaściwej ścieżki. Należy więc precyzyjnie określić Destination networks i Services.
• Reply Packets pomylone ze zwykłymi nowymi połączeniami: Analizowana jest wtedy niewłaściwa przyczyna. Należy sprawdzić Packet Capture i kierunek Flow.
• Poszukiwanie Firewall Rule dla ruchu generowanego przez system: Ten ruch ma Firewall Rule ID 0; zwykłe reguły zapory nim nie sterują. Należy sprawdzić Route, Service, Live Connection i w razie potrzeby sys-traffic-nat.
• Traktowanie Direct Web Proxy jak zwykłego ruchu HTTP/HTTPS: W przypadku bezpośredniego Proxy trasa SD-WAN musi obejmować port skonfigurowany w Web > General settings > Web proxy listening port. Alternatywnie Services może mieć wartość Any. Source Network i Incoming Interface nie dopasowują Reply Packets ruchu Proxy; dla drogi powrotnej potrzebny jest co najmniej jeden WAN-Gateway lub odpowiednia trasa statyczna.
• Kilka zmian routingu jednocześnie: Przyczyna błędu pozostaje niejasna. Zmiany należy wprowadzać etapami i dokumentować każdy test.
• Brak alternatywnego dostępu administracyjnego: Dostęp do WebAdmin lub SSH z objętej zmianą sieci może zostać utracony. Należy przygotować okno serwisowe i inną ścieżkę dostępu.

Szczególnie duże ryzyko powstaje przy połączeniu kilku warunków: Route Precedence ustawia SD-WAN przed Static, szeroka trasa SD-WAN korzysta z Any, a routing SD-WAN dla ruchu generowanego przez system lub Reply Packets jest aktywny. W takim przypadku można utracić dostęp do WebAdmin lub SSH z określonych podsieci wewnętrznych.

Współdziałanie z NAT, IPsec i VoIP

SD-WAN rzadko jest jedynym elementem problemu. W wielu awariach znaczenie mają również NAT, IPsec lub ruch specyficzny dla aplikacji.

W przypadku SNAT istotne jest, czy ten sam Source IP zostaje zachowany przy różnych Gateway. Bieżący stan można odczytać w Device Console za pomocą show routing reroute-connection i show routing reroute-snat-connection. SFOS może przekierować połączenia po awarii Gateway, ale połączenia SNAT muszą zachować ten sam adres źródłowy po translacji na obu ścieżkach. MASQ lub różne adresy po translacji mogą przerwać aktywną komunikację podczas reroutingu. W tym artykule te dwie wartości są tylko odczytywane, a nie zmieniane. Podstawy opisano w artykule NAT na Sophos Firewall.

W przypadku route-based IPsec VPN interfejsy XFRM mogą być używane w SD-WAN Routes lub SD-WAN Profiles. Należy wtedy łącznie sprawdzić status IPsec, trasę SD-WAN, Route Precedence i reguły zapory. Podstawy route-based VPN przedstawia artykuł Trasa IPsec w Sophos Firewall.

Przy problemach z VoIP warto dodatkowo przeanalizować SIP, RTP, NAT i SD-WAN. Release Notes dla SFOS 22.0 MR1 dokumentują naprawiony problem, w którym po aktualizacji do SFOS 22.0 GA dźwięk VoIP przez route-based VPN z routingiem SD-WAN działał tylko w jednym kierunku. Praktyczną procedurę zawiera artykuł Rozwiązywanie problemów VoIP z SIP i RTP w Sophos Firewall.

Rollback i zakończenie

Rollback

Przed zmianą należy udokumentować wcześniejszy stan. Jeśli po zmianie problem dotyczy dostępu administracyjnego, usług systemowych lub ruchu produkcyjnego, nie należy dalej improwizować. Najpierw trzeba przywrócić poprzedni stan.

W praktyce oznacza to:

1. Przywróć udokumentowane wcześniejsze wartości reply-packet i system-generate-traffic za pomocą odpowiednich poleceń enable lub disable.
2. Przywróć wcześniejszą kolejność Route Precedence, jeśli została zmieniona.
3. Przywróć zmienione trasy SD-WAN do udokumentowanych wcześniejszych wartości; trasy utworzone tylko na potrzeby testu usuń po sprawdzeniu zależności.
4. Usuń tymczasowe wpisy sys-traffic-nat z dokładnie tymi samymi selektorami i sprawdź wynik za pomocą show advanced-firewall.
5. Przywróć reguły zapory, obiekty Gateway, zezwolenia Device Access i ustawienia logowania zmienione tylko na potrzeby testu.
6. Przetestuj dostęp administracyjny i pierwotną ścieżkę danych z sieci nieobjętej problemem.
7. Dopiero potem kontynuuj zawężanie właściwej przyczyny.

Jeśli dostęp do WebAdmin i SSH z jednej podsieci wewnętrznej zostanie utracony, ale z innej nadal działa, należy z niej najpierw sprawdzić szeroką trasę SD-WAN, Route Precedence i obie opcje CLI.

Lista kontrolna

• Udokumentowano bieżący stan obu opcji CLI.
• Udokumentowano Route Precedence za pomocą system route_precedence show.
• Dokładnie zdefiniowano analizowany ruch.
• Dla System Traffic użyto tylko Destination i Service jako decydujących kryteriów dopasowania.
• Trasa SD-WAN nie została niepotrzebnie rozszerzona za pomocą Any.
• Sprawdzono Route Precedence.
• Co najmniej jeden WAN-Gateway dla System Traffic ma status Active.
• Przygotowano alternatywne połączenie administracyjne.
• W każdym teście wprowadzano tylko jedną zmianę.
• Do walidacji użyto Log Viewer i Packet Capture.
• Sprawdzono również NAT, IPsec i reguły zapory.
• Wynik i rollback udokumentowano w dzienniku operacyjnym.

FAQ