Konfiguracja Sophos Firewall jako serwera DHCP

Sophos Firewall może bezpośrednio przydzielać klientom adresy IPv4, bramę, serwery DNS i inne ustawienia sieciowe. W tym celu w Network > DHCP należy utworzyć serwer dla interfejsu klientów, zdefiniować pulę adresów, a następnie sprawdzić, czy klient otrzymuje prawidłową dzierżawę.

Skrócona procedura: otworzyć Network > DHCP > Server > Add, wybrać interfejs i pulę adresów, włączyć Use interface IP as gateway, starannie skonfigurować ustawienia DNS i zapisać konfigurację. Następnie w System services > Services sprawdzić usługę DHCP server, a przydzielony adres skontrolować w sekcji IPv4 lease.

Ten poradnik dotyczy serwera DHCPv4 dla klientów w bezpośrednio podłączonej sieci. Jeżeli centralny serwer DHCP ma obsługiwać inną podsieć, odpowiedni jest artykuł Konfiguracja i testowanie DHCP Relay na Sophos Firewall. Ustawienia PXE, VoIP i wartości specyficzne dla producentów opisano w artykule Konfiguracja opcji DHCP na Sophos Firewall.

W IPv6 przydzielanie adresów i domyślna brama pełnią odrębne role. Pełną procedurę opisuje artykuł Konfigurowanie i testowanie serwera DHCPv6 na Sophos Firewall.

Przykład i planowanie adresacji

W przykładzie użyto VLAN-u klientów z następującymi wartościami:

Interfejs: VLAN20 - 10.20.0.1/24
Pula dynamiczna: od 10.20.0.100 do 10.20.0.199
Brama: 10.20.0.1
Statyczne przypisanie dla drukarki: 10.20.0.20
Wewnętrzne serwery DNS: 10.10.0.10 i 10.10.0.11
Domain Name: corp.example

Pula dynamiczna znajduje się w sieci interfejsu, ale nie obejmuje adresu sieci, adresu rozgłoszeniowego ani bramy. W tym przykładzie adresy poniżej 10.20.0.100 pozostają zarezerwowane dla infrastruktury i przypisań statycznych. Dzięki temu ta pula DHCP nie przydziela dodatkowo zarezerwowanych adresów w sposób dynamiczny. Taki podział nie chroni jednak przed innym urządzeniem, na którym ręcznie skonfigurowano ten sam adres IP.

Przed aktywacją należy sprawdzić, które adresy są już używane przez przełączniki, punkty dostępowe, drukarki lub serwery. Jeżeli w tym samym VLAN-ie nadal działa inny serwer DHCP, najpierw trzeba ustalić, który serwer będzie odtąd odpowiedzialny za przydzielanie adresów. Dwa nieskoordynowane serwery mogą przekazywać różne bramy lub serwery DNS i powodować sporadyczne, trudne do przewidzenia problemy.

Sam interfejs musi już mieć prawidłowy statyczny adres IP. Współdziałanie interfejsu, strefy i VLAN-u wyjaśnia artykuł Konfiguracja interfejsu VLAN na Sophos Firewall.

Konfiguracja serwera DHCP

⚠️ W klastrze HA Sophos obsługuje usługę DHCP w trybie Active-passive, ale nie w trybie Active-active. Sprawdzić ten warunek przed utworzeniem serwera DHCP; zmiana trybu HA nie jest krokiem diagnostycznym dla pojedynczego zakresu.

Otworzyć Network > DHCP.
W sekcji Server kliknąć Add.
Wpisać jednoznaczną nazwę, na przykład dhcp-vlan20-clients.
W polu Interface wybrać interfejs klientów VLAN20 - 10.20.0.1.
W sekcji Dynamic IP lease dodać pulę od 10.20.0.100 do 10.20.0.199.
W polu Subnet mask wpisać 255.255.255.0 dla przykładowej sieci /24.
Włączyć Use interface IP as gateway. Klienci otrzymają wtedy 10.20.0.1 jako Gateway.
Ustawić serwery DNS, Domain name i czasy dzierżawy odpowiednio do sieci.
W razie potrzeby dodać statyczne przypisania MAC-IP.
Zapisać przyciskiem Save.

W przypadku klientów podłączonych bezpośrednio wybrany interfejs określa sieć, w której zapora odpowiada na żądania DHCP. Dlatego pula dynamiczna musi należeć do podsieci tego interfejsu. Serwery DHCP można konfigurować na interfejsach fizycznych oraz interfejsach VLAN, Wireless i Bridge, ale nie na interfejsie typu Interface Alias. Na interfejsie używanym już jako DHCP Relay nie można jednocześnie skonfigurować serwera DHCPv4.

Dla klientów podłączonych bezpośrednio opcja Accept client request via relay pozostaje wyłączona. Należy ją włączyć tylko wtedy, gdy ta konfiguracja serwera ma przyjmować za pośrednictwem agenta przekazującego DHCP żądania z odległej podsieci klientów. Każda taka sieć wymaga odpowiedniej konfiguracji serwera z własną bramą; pełny projekt opisuje instrukcja DHCP Relay.

Te konfiguracje serwera mogą korzystać z tego samego interfejsu DHCP, na którym serwer odbiera przekazane żądania. Należy odróżnić interfejs nasłuchujący od odległej podsieci klientów: pula adresów, maska podsieci i brama każdej konfiguracji należą do odpowiedniej sieci klientów. Serwer przydziela adresy z podsieci adresu źródłowego agenta przekazującego; wspólny interfejs nasłuchujący nie zastępuje więc oddzielnej konfiguracji dla każdej sieci klientów.

Prawidłowy wybór bramy i DNS

W typowej sieci klientów bramą jest adres IP Sophos Firewall na tym interfejsie. Dlatego w przykładzie klienci otrzymują adres 10.20.0.1.

Opcja Use device’s DNS settings powoduje, że zapora przekazuje klientom skonfigurowane na niej serwery DNS. Jest to właściwe rozwiązanie, jeżeli te serwery potrafią rozwiązywać zarówno nazwy publiczne, jak i wymagane nazwy wewnętrzne. W środowisku AD zwykle należy podać wewnętrzne serwery DNS, aby kontrolery domeny, usługi wewnętrzne i domeny wyszukiwania działały niezawodnie. Same publiczne resolwery zazwyczaj nie wystarczą.

Domain name przekazuje sufiks DNS do karty sieciowej. Przy wartości corp.example klient może na przykład uzupełnić nazwę hosta fileserver do fileserver.corp.example. Nie zastępuje to ani rekordu DNS, ani osiągalnego serwera DNS; oba elementy trzeba sprawdzić oddzielnie.

Jeżeli klienci otrzymują adres IP zapory jako serwer DNS, Sophos Firewall może przekazywać zapytania dotyczące określonych stref wewnętrznych do właściwych serwerów. Ten przypadek opisano w artykule Konfiguracja DNS Request Routes na Sophos Firewall. Jeżeli natomiast DHCP przekazuje bezpośrednio adresy innych serwerów DNS, zapytania klientów nie trafiają do Request Routes na zaporze.

Pola WINS server 1 i WINS server 2 są przeznaczone wyłącznie dla starszych środowisk NetBIOS. Należy pozostawić je puste, jeżeli żaden klient ani żadna aplikacja nie wymaga usługi WINS. Jeżeli WINS jest nadal używany, trzeba wpisać rzeczywiste adresy serwerów i sprawdzić rozwiązywanie nazw na odpowiednim kliencie.

Ustawianie odpowiednich czasów dzierżawy

Default lease time to standardowy czas dzierżawy przekazywany klientowi. Max lease time jest wartością maksymalną; po jej upływie klient musi wysłać nowe żądanie do serwera DHCP. Obie wartości podaje się w minutach.

Dłuższe dzierżawy są odpowiednie w stabilnych sieciach biurowych lub sieciach urządzeń, w których liczba klientów rzadko się zmienia. W sieciach dla gości, środowiskach szkoleniowych lub sieciach WLAN o dużej rotacji klientów krótsza dzierżawa zapobiega długotrwałemu zajmowaniu puli przez urządzenia, które nie są już połączone.

Bardzo krótkie dzierżawy powodują natomiast niepotrzebnie wiele odnowień. Decydujące znaczenie ma więc nie jedna uniwersalna wartość, lecz rozmiar puli i częstotliwość zmian klientów.

Conflict detection sprawdza adres przed jego przydzieleniem i pomaga wykrywać już używane adresy IP. Funkcja jest szczególnie przydatna, gdy nadal występują urządzenia skonfigurowane ręcznie albo starsza, nie w pełni udokumentowana adresacja.

Tworzenie statycznego przypisania IP-MAC

Statyczne przypisanie sprawia, że określone urządzenie zawsze otrzymuje przez DHCP ten sam adres. Jest to przydatne dla drukarek, punktów dostępowych i innych urządzeń, które muszą pozostać osiągalne, ale powinny nadal otrzymywać centralnie skonfigurowane wartości, takie jak brama i DNS.

W sekcji Static IP MAC mapping należy podać nazwę hosta, adres MAC i wymagany adres IP. W przykładzie drukarka z rzeczywistym adresem MAC zawsze otrzymuje 10.20.0.20. Adres ten celowo znajduje się poza pulą dynamiczną.

Przypisanie DHCP nie jest tym samym co adres IP skonfigurowany ręcznie na urządzeniu: urządzenie pozostaje klientem DHCP, ale zapora rezerwuje dla niego właściwą dzierżawę. Jeżeli laptop lub smartfon używa prywatnego albo losowego adresu MAC w sieci WLAN, przypisanie musi odpowiadać adresowi MAC, którego urządzenie faktycznie używa w tej sieci WLAN.

Do jednego adresu MAC można przypisać maksymalnie pięć statycznych adresów IP, o ile znajdują się w różnych podsieciach. Zwykłe przypisanie w jednej sieci nie wymaga ustawienia globalnego.

W SFOS 23, gdy ten sam adres MAC jest przypisany w wielu konfiguracjach serwera DHCP, w Network > DHCP > Advanced server settings ustawić Lease scope for static binding na Global. Klienci mogą wtedy uzyskać adres z dowolnego serwera DHCP skonfigurowanego na zaporze, niezależnie od tego, gdzie zapisano statyczne przypisanie IP-MAC. Network ogranicza to do serwera zawierającego przypisanie. Najpierw zapisać poprzednią wartość, a następnie przetestować każdy objęty zakres z nową dzierżawą klienta. Przy wycofywaniu zmiany przywrócić dokładnie zapisaną wartość.

SFOS 22: globalne przypisanie przez Device Console

Przed zmianą przypisania globalnego należy po zalogowaniu się przez SSH sprawdzić w Device Console lokalną pomoc dotyczącą konkretnych poleceń conf-generation-method i static-entry-scope w zainstalowanej wersji SFOS. Bieżącą metodę i bieżący zakres należy ustalić i zapisać za pomocą obsługiwanego w tej wersji zapytania tylko do odczytu lub dostępnego widoku w interfejsie użytkownika; należy również wcześniej sprawdzić odpowiednią składnię wycofania zmiany. Forma polecenia show zależy od wersji; przed użyciem sprawdź pomoc zainstalowanego buildu. Jeśli nie można wiarygodnie ustalić stanu początkowego lub sposobu jego przywrócenia, nie należy wprowadzać zmian, lecz najpierw wyjaśnić stan z pomocą techniczną.

Następnie należy zmienić tylko te wartości, które różnią się od wymaganego stanu docelowego:

system dhcp conf-generation-method new
system dhcp static-entry-scope global

Ustawienie dotyczy wszystkich konfiguracji serwera DHCP. Nie jest wymagane w przypadku zwykłych, pojedynczych przypisań, dlatego należy je zmieniać wyłącznie w opisanym przypadku wielu zakresów.

W przypadku adresów MAC przypisanych wielokrotnie przedstawiony powyżej stan docelowy jest ważny, aby klienci otrzymywali prawidłowe informacje DHCP, takie jak serwery DNS i brama. Nie należy nadpisywać już prawidłowego stanu ani zakładać, że stan początkowy odpowiada wartościom domyślnym. Przy wycofywaniu zmiany należy przywrócić dokładnie wcześniej zapisane wartości, używając składni potwierdzonej dla zainstalowanej wersji. Jeśli wartości początkowe rzeczywiście wynosiły network i old, można w tym celu użyć system dhcp static-entry-scope network i system dhcp conf-generation-method old, o ile lokalna pomoc potwierdza te formy. Następnie należy sprawdzić każdy objęty zakres z nową dzierżawą klienta.

Sprawdzanie usługi i testowanie dzierżawy

Po zapisaniu konfiguracji należy w System services > Services sprawdzić, czy DHCP server działa. Jeśli usługa jest zatrzymana, należy uruchomić ją w tym miejscu.

Następnie trzeba podłączyć kontrolowanego klienta testowego do właściwego VLAN-u. W systemie Windows nową dzierżawę można uzyskać i sprawdzić za pomocą następujących poleceń:

⚠️ Polecenie ipconfig /release przerywa bieżące połączenie IPv4. Nie należy wykonywać go przez to samo połączenie zdalne, jeżeli nie ma alternatywnego dostępu.

ipconfig /release
ipconfig /renew
ipconfig /all

Klient powinien otrzymać adres z zakresu od 10.20.0.100 do 10.20.0.199, bramę 10.20.0.1 oraz przewidziane serwery DNS. W sekcji Network > DHCP > IPv4 lease zapora wyświetla przydzielony adres wraz z czasem rozpoczęcia i zakończenia, adresem MAC oraz nazwą hosta.

Test funkcjonalny powinien potwierdzić co najmniej następujące punkty:

Klient otrzymuje adres z właściwej puli.
Brama i serwery DNS są zgodne z planem.
Brama jest osiągalna.
Nazwy wewnętrzne i zewnętrzne są rozwiązywane.
Klient ma dostęp wyłącznie do sieci i usług dozwolonych przez jego regułę zapory.

Brak adresu lub nieprawidłowy adres

Jeżeli klient nie otrzymuje dzierżawy, należy najpierw sprawdzić interfejs, VLAN i stan usługi. Następnie szczególnie często występują następujące błędy:

Nieprawidłowy interfejs: serwer DHCP nie jest przypisany do interfejsu sieci klientów.
VLAN nie dociera do zapory: uplink przełącznika nie przepuszcza VLAN-u jako tagged albo port klienta jest przypisany nieprawidłowo.
Pula adresów jest nieprawidłowa: adres początkowy lub końcowy znajduje się poza podsiecią interfejsu.
Pula jest wyczerpana: należy porównać liczbę i czas trwania zajętych dzierżaw z rozmiarem skonfigurowanej puli. Lista dzierżaw pokazuje adresy przydzielone, ale nie zawiera osobnej listy wolnych adresów.
Odpowiada inny serwer DHCP: klient otrzymuje adres, ale nieprawidłową bramę lub serwery DNS.
Policy rule denied dla źródła 0.0.0.0: jeżeli na interfejsie nie skonfigurowano ani serwera DHCP, ani funkcji DHCP Relay, żądanie klienta może zostać odrzucone z takim wpisem. Komunikat nie dowodzi więc, że przyczyną jest zwykła reguła zapory. Najpierw należy sprawdzić serwer DHCP, relay i przypisanie interfejsu.
Wymagany byłby DHCP Relay: klient nie znajduje się w sieci bezpośrednio podłączonej do serwera.
Statyczne przypisanie nie działa: wprowadzony adres MAC nie odpowiada adresowi MAC faktycznie używanemu przez klienta.

Przechwytywanie pakietów z filtrem port 67 or port 68 pozwala sprawdzić, czy wymieniane są komunikaty Discover, Offer, Request i ACK oraz który serwer odpowiada. Obsługę narzędzia opisano w artykule Korzystanie z Packet Capture w WebAdmin Sophos Firewall.

Jeżeli komunikat Discover dociera do zapory, ale nie następuje po nim Offer, należy dodatkowo sprawdzić stan dhcpd i dziennik dhcpd.log. Odpowiednie polecenia i ścieżki dzienników przedstawiono w artykule Sprawdzanie usług i dzienników Sophos Firewall przez CLI.

Jeżeli klient otrzymuje prawidłowy adres IP, ale nie może rozwiązywać nazw, należy najpierw sprawdzić adresy DNS przekazywane przez DHCP. Jeśli są nieprawidłowe lub ich brakuje, błąd nadal znajduje się w konfiguracji DHCP. Jeżeli są poprawne, należy następnie sprawdzić wewnętrzne rozwiązywanie nazw i dostęp sieciowy do serwera DNS.

Interfejs RED ma dodatkowy przypadek szczególny: jeżeli jego adres zostanie zmieniony na adres spoza dotychczasowej dynamicznej puli dzierżaw, SFOS wyłączy powiązany serwer DHCP RED. Następnie trzeba dostosować Dynamic IP lease, przypisania statyczne i wartości DNS do wynikowej podsieci interfejsu albo utworzyć nową konfigurację serwera. Dopiero potem można ponownie oddać zakres do użytku i sprawdzić go za pomocą klienta.

Zastępowanie istniejącego serwera DHCP

Podczas migracji nie należy po prostu aktywować nowego serwera DHCP równolegle. Aktywni klienci zachowują dotychczasową dzierżawę; nowy serwer nie zna tych przydziałów i może ponownie zaoferować nadal używany adres.

Aby przeprowadzić kontrolowaną zmianę:

Udokumentować pulę, opcje, przypisania statyczne i aktywne dzierżawy dotychczasowego serwera.
Odpowiednio wcześnie skrócić czas dzierżawy na starym serwerze i poczekać, aż aktywni klienci odnowią dzierżawę z krótszą wartością.
Zatrzymać dotychczasowy serwer i początkowo uruchomić nowy serwer z niepokrywającą się pulą przejściową.
Odnowić dzierżawy na kilku różnych klientach oraz sprawdzić bramę, DNS i osiągalność.
Po wygaśnięciu starych dzierżaw włączyć docelową pulę i przywrócić standardowy czas dzierżawy.

Conflict detection jest pomocne podczas migracji, ale nie zastępuje takiego planowania. Funkcja sprawdza adres przed przydzieleniem, ale nie współdzieli bazy danych dzierżaw ze starym serwerem.

Na potrzeby wycofania zmiany trzeba zachować pełny zapis poprzedniej konfiguracji. Jeżeli nowy zakres przekazuje błędne wartości, należy wyłączyć lub usunąć wyłącznie tę nową konfigurację serwera i w kontrolowany sposób ponownie uruchomić poprzedni serwer. Polecenie System services > Services > DHCP server > Stop zatrzymuje natomiast globalną usługę DHCP, a więc wszystkie lokalne zakresy; należy go używać tylko wtedy, gdy zamierzony jest właśnie taki pełny skutek. Następnie trzeba odnowić dzierżawy na kilku klientach testowych.

Specjalne wartości, takie jak serwery rozruchowe PXE, kontrolery VoIP lub opcje producentów, należy przed przełączeniem porównać osobno. Nie są one automatycznie częścią standardowego przydzielania adresu, bramy i DNS.

Automatyzacja: stan nazwanej konfiguracji DHCP

Dokumentacja API XML dla SFOS 22 i 23 opisuje DHCPServerStatus z wymaganymi polami DHCPServerNamedhcpname i Status. DHCPServerNamedhcpname to dosłowna pisownia z dokumentacji, a nie poprawiona tutaj nazwa pola. Nazwa wskazuje wybraną konfigurację serwera DHCP, na przykład dhcp-vlan20-clients, a nie globalną usługę DHCP. Zmiany stanu tego nazwanego zakresu nie należy mylić z opisanym powyżej globalnym Stop.

W przypadku Status przykład pokazuje ON/OFF, natomiast tabela parametrów podaje INTEGER. Nie podano mapowania liczbowego ani wartości domyślnej; oba pola są wymagane. Nie można zatem ustalić bezpiecznego kodowania ani zachowania po pominięciu pól. Nie należy automatyzować zmiany stanu przez XML na podstawie tego przykładu. Dopóki schemat pól i kodowanie stanu nie zostaną wyjaśnione dla zainstalowanej wersji, należy korzystać z istniejącej procedury GUI w Network > DHCP dla wybranej konfiguracji serwera; usługą globalną zarządza się oddzielnie w System services > Services.

Przed zmianą zapisać nazwę, interfejs, pulę adresów i poprzedni stan docelowego zakresu. Następnie sprawdzić dokładnie tę konfigurację oraz brak zmian w pozostałych zakresach i przeprowadzić na kontrolowanych klientach opisane powyżej kontrole dzierżawy, bramy, DNS i osiągalności. Przy wyłączaniu sprawdzić, czy ten zakres nie przydziela już nowych dzierżaw; nadal istniejąca dzierżawa klienta tego nie dowodzi. Udokumentowane wyniki API 200 (Operation Successful) i 500 (Operation Fail) nie są testami funkcjonalnymi; sam HTTP 200 również nie potwierdza ani prawidłowego celu, ani stanu klienta. Przy wycofywaniu zmiany przywrócić dokładnie zapisany stan i powtórzyć kontrole klientów.

Globalne ustawienia DHCP zmieniać tylko w razie potrzeby

W SFOS 23 w Network > DHCP > Advanced server settings znajdują się te dwa pola interfejsu:

Allow only one lease per client ogranicza każdego klienta do jednej dzierżawy DHCP. Po włączeniu opcji każdy klient otrzymuje tylko jeden dzierżawiony adres IP.
Negative acknowledgement włącza odpowiedzi DHCPNAK, gdy klient żąda adresu spoza skonfigurowanej podsieci serwera lub adresu już przydzielonego. Conflict detection to natomiast oddzielne sprawdzenie adresu przed jego przydzieleniem.

Przed zmianą w interfejsie należy zapisać poprzednią wartość. Następnie odnowić dzierżawę klienta, sprawdzić IPv4 lease i w razie potrzeby przechwycone pakiety UDP 67/68. Przy wycofywaniu zmiany przywrócić dokładnie zapisaną wartość. Nadal obowiązują poniższe wskazówki CLI dotyczące globalnego wpływu, identyfikacji klienta i ryzyka związanego z NAK.

Dwa dodatkowe przełączniki Device Console wpływają na całą usługę DHCP. Przed zmianą należy sprawdzić lokalną pomoc dotyczącą konkretnych poleceń one-lease-per-client i send-dhcp-nak w zainstalowanej wersji. Należy zapisać bieżący stan obu przełączników za pomocą obsługiwanego w tej wersji zapytania tylko do odczytu lub dostępnego widoku w interfejsie użytkownika oraz potwierdzić składnię zmiany i jej wycofania. Nie zakłada się tutaj, że określona forma show lub wartość domyślna obowiązuje we wszystkich wersjach. Jeśli nie można wiarygodnie ustalić stanu początkowego lub sposobu jego przywrócenia, nie należy wprowadzać zmian, lecz najpierw skontaktować się z pomocą techniczną.

Po włączeniu one-lease-per-client ogranicza przydzielanie dzierżaw na klienta. Sposób, w jaki zainstalowana wersja identyfikuje klienta w przypadkach szczególnych, należy ustalić lokalnie. Włączenie dotyczy wszystkich konfiguracji serwera DHCP na tej zaporze; dlatego początkowo należy ograniczyć jedynie test do kontrolowanego klienta, a następnie sprawdzić tabelę dzierżaw, odnowienie oraz urządzenia z wieloma interfejsami lub zmieniającym się adresem MAC.

Włączony send-dhcp-nak umożliwia wysyłanie odpowiedzi DHCPNAK. DHCPNAK odrzuca adres nieakceptowany przez serwer i wymusza na kliencie powrót do negocjacji DHCP. Wyłączenie może przedłużać nieprawidłowe stany klientów i nie jest uniwersalnym rozwiązaniem problemów z uzyskiwaniem dzierżaw.

Przełączniki należy zmieniać w następujący sposób wyłącznie wtedy, gdy lokalna pomoc potwierdza tę składnię dla zainstalowanej wersji, a stan początkowy i sposób jego przywrócenia zostały zapisane:

system dhcp one-lease-per-client [enable|disable]
system dhcp send-dhcp-nak [enable|disable]

Nawiasy kwadratowe są symbolami zastępczymi; należy wykonać polecenie tylko z wymaganą wartością. Po zmianie należy ponownie sprawdzić wartość za pomocą tego samego obsługiwanego zapytania tylko do odczytu lub widoku w interfejsie użytkownika, odnowić dzierżawę, skontrolować IPv4 lease i w razie potrzeby przechwycić pakiety UDP 67/68. Przy wycofywaniu zmiany należy przywrócić dokładnie wartości zapisane przed zmianą, używając wcześniej potwierdzonej składni, i ponownie sprawdzić oba przełączniki. system dhcp one-lease-per-client disable oraz system dhcp send-dhcp-nak enable są odpowiednimi poleceniami przywracającymi stan tylko wtedy, gdy odpowiednio pierwszy przełącznik był wcześniej wyłączony, a drugi wcześniej włączony, oraz gdy lokalna pomoc potwierdza tę składnię.