Opcje DHCP w Sophos Firewall (SFOS)

Opcje DHCP są potrzebne na Sophos Firewall, gdy klienci podczas uruchamiania potrzebują więcej niż tylko adresu IP, bramy i DNS. Typowe przypadki to PXE, WDS, Thin Clients, telefony VoIP lub starsze środowiska RED, gdzie określony kod opcji i typ danych muszą dokładnie pasować.

Aktualne wersje Sophos Firewall obsługują opcje DHCP bezpośrednio w WebAdmin. Dla większości środowisk nie jest już konieczna konfiguracja SSH lub CLI. Przykłady CLI pozostają jednak ważne, ponieważ starsze runbooki, specjalne przypadki i rozwiązywanie problemów często nadal używają tej składni.

Czym są opcje DHCP

DHCP nie tylko przydziela adres IP. Wraz z dzierżawą serwer DHCP może przekazywać klientowi dodatkowe informacje. Właśnie do tego służą opcje DHCP. Typowe przykłady to serwery DNS, brama, serwer TFTP, nazwa pliku startowego, parametry specyficzne dla dostawcy lub wartości dla Thin Clients i telefonów.

Na Sophos Firewall opcje DHCP zawsze należą do serwera DHCP lub zakresu, który wydaje dzierżawę. To ważne: jeśli klient otrzymuje swój adres od innego serwera DHCP, opcja musi być tam skonfigurowana. Jeśli Sophos Firewall działa tylko jako przekaźnik DHCP, przekazuje zapytania DHCP, ale nie jest miejscem, gdzie opcja dla tego zakresu jest utrzymywana.

Dla IPv6 DHCP nie zawsze jest traktowane tak samo jak dla IPv4. Jeśli dostawca deleguje prefiks IPv6, reklama routera, parametry DHCPv6 i zasady zapory są ze sobą powiązane. Proces ten jest opisany w Konfigurowanie delegacji prefiksu IPv6 na Sophos Firewall.

W praktyce przed konfiguracją należy wyjaśnić trzy rzeczy:

• Który serwer DHCP faktycznie rozdziela dzierżawę?
• W jakim zakresie lub na jakim interfejsie znajduje się klient?
• Jakie kody opcji, typy danych i wartości wymaga producent docelowego systemu?

Wymagania

• Sophos Firewall z włączonym serwerem DHCPv4
• Dostęp do Network > DHCP
• Zakres DHCP na odpowiednim interfejsie
• Wymagane kody opcji DHCP i wartości producenta lub systemu docelowego
• Dla CLI-fallbacks: dozwolony dostęp SSH do Sophos Firewall

Przed zmianą należy krótko sprawdzić dotknięty zakres. Opcje DHCP działają niezawodnie tylko wtedy, gdy są ustawione na właściwym serwerze DHCP, w odpowiedniej sieci i z właściwym typem danych.

• Serwer DHCP: Sophos Firewall musi sam wystawiać lease. Przy DHCP Relay opcje zwykle konfiguruje się na centralnym serwerze DHCP.
• Zakres i interfejs: Klient w niewłaściwym VLAN-ie lub na innym interfejsie nie zobaczy opcji, nawet jeśli została poprawnie zapisana.
• Kod opcji i typ danych: Wiele błędów wynika z tego, że klient oczekuje string, ipaddress, array-of lub wartości producenta inaczej niż zostało to wpisane.
• Klient testowy: Znane urządzenie w danej sieci pokazuje, czy opcja rzeczywiście trafia w DHCP offer lub ACK.
• Okno zmian: PXE, telefony i thin clients mogą zostać dotknięte natychmiast po zmianie lease. Dlatego zmiany należy testować kontrolowanie.

Jeśli opcja jest istotna dla urządzeń produkcyjnych, należy wcześniej wiedzieć, jak ją usunąć lub przywrócić do poprzedniej wartości. Dotyczy to szczególnie opcji startowych, serwerów provisioningowych i opcji dostawcy specyficznych dla producenta.

1. Utwórz lub sprawdź serwer DHCP

Aby opcje DHCP mogły być dystrybuowane, najpierw potrzebny jest serwer DHCPv4 na Sophos Firewall. Jest on tworzony lub edytowany w WebAdmin pod Network > DHCP.

Najważniejsze jest:

• Serwer DHCP jest przypisany do interfejsu.
• Zakres pasuje do sieci, w której znajdują się klienci.
• Serwery DNS, brama i czas dzierżawy są poprawnie ustawione.
• Nazwa DHCP nie zawiera zbędnych spacji ani znaków specjalnych.
• Przypadki specjalne PXE, VoIP, Thin Client lub RED są wcześniej udokumentowane.

Szczególnie nazwa DHCP jest istotna przy poleceniach CLI. Jeśli nazwa zawiera spacje lub znaki specjalne, późniejsze polecenia i runbooki stają się niepotrzebnie podatne na błędy. Zrozumiałe nazwy, takie jak DHCP_Server_Avanet_LAN, Home_Scope lub DHCP_VoIP, są w praktyce łatwiejsze.

2. Konfiguracja opcji DHCP w WebAdmin

Gdy serwer DHCPv4 jest już utworzony, opcje można dodać bezpośrednio w tym samym dialogu.

1. Otwórz Network > DHCP.
2. Edytuj istniejący serwer DHCPv4 lub utwórz nowy serwer.
3. Przejdź do sekcji DHCP options.
4. Dodaj opcję.
5. Dla własnych opcji ustaw Options na Custom i wprowadź Code, Type oraz Value.
6. Zapisz zmiany.
7. Sprawdź za pomocą klienta testowego, czy opcja została rzeczywiście przyjęta.

Pola oznaczają:

• Options albo Option: Wybór między predefiniowanymi opcjami DHCP a własnymi opcjami custom. Przy opcjach Custom kod opcji wprowadza się ręcznie.
• Code: Numeryczny kod opcji DHCP, na przykład 66, 67, 161 albo wartość specyficzna dla producenta.
• Type: Typ danych wartości, na przykład ipaddress, string, boolean, one-byte, two-byte, four-byte albo array-of.
• Value: Konkretna wartość, którą ma otrzymać klient, na przykład adres IP, nazwa hosta, ścieżka albo port.

Poprawne wartości zazwyczaj dostarcza producent systemu docelowego. Zwłaszcza w przypadku wartości typu string, ścieżek lub opcji specyficznych dla dostawcy warto sprawdzić dokumentację producenta. Formalnie zapisany wartość nie oznacza automatycznie, że klient zinterpretuje ją tak, jak się oczekuje.

3. Typowe przypadki użycia

Opcje DHCP są najczęściej potrzebne, gdy klient podczas uruchamiania potrzebuje dodatkowych informacji. Częste przypadki to PXE, WDS, Thin Clients, telefony VoIP, punkty dostępu lub pojedyncze scenariusze legacy.

PXE i WDS

Dla środowisk PXE lub WDS często używane są opcje 66 i 67:

• 66 wskazuje na serwer TFTP lub Deployment.
• 67 zawiera nazwę pliku startowego.

Jeśli klient osiąga serwer, ale nie bootuje, problem często nie leży po stronie zapory, ale w nieprawidłowej ścieżce pliku, nieodpowiednim typie danych lub niepasującej architekturze pliku. Klienci UEFI i BIOS często wymagają różnych plików startowych.

Ważne w aktualnych wersjach SFOS: Next-server i Boot file są osobnymi polami boot option w serwerze DHCPv4. Od SFOS 20.0 MR1 nie są już automatycznie traktowane wyłącznie jako opcje DHCP 66 i 67. Jeśli urządzenie wyraźnie oczekuje opcji 66 lub 67, należy świadomie utrzymywać te wartości w DHCP options, a nie tylko wypełniać pola boot option.

Przy aktualizacji do SFOS 20.0 MR1 lub nowszej istniejące wartości Next-server i Boot file pozostają jako boot options oraz dodatkowo jako opcje DHCP 66 i 67. Po migracji należy więc sprawdzić, czy wartości nie występują podwójnie i czy klient analizuje oczekiwany wariant.

Thin Clients

Thin Clients wymagają w zależności od producenta opcji dla serwera zarządzania, serwera obrazów lub parametrów połączenia. W starych runbookach można znaleźć na przykład:

• 161 dla serwera
• 192 dla portu lub dodatkowych parametrów

Czy te kody są poprawne, zależy od producenta i używanego modelu Thin Client. Dlatego nie należy ich przyjmować na ślepo, ale zawsze sprawdzać w dokumentacji producenta.

Starsze przypadki specjalne RED

W starszych środowiskach zdarzały się przypadki, w których zintegrowany punkt dostępu w Sophos RED 15w nie był poprawnie rozpoznawany. W tym celu czasami używano specyficznej dla producenta opcji DHCP, na przykład z kodem opcji 234 i wartością jak 10.10.10.12.

To nie jest ogólny standard dla nowoczesnych instalacji SD-RED. Jako przykład legacy jest jednak nadal przydatny, ponieważ pokazuje, jak definiować własne kody opcji i przypisywać je do serwera DHCP.

Dla aktualnych projektów RED artykuł Konfigurowanie i rozwiązywanie problemów z Sophos SD-RED jest bardziej pomocny. Jeśli chodzi o projektowanie interfejsów, VLAN, mostków lub RED, dodatkowo pomocny jest Planowanie i konfigurowanie stref i interfejsów Sophos Firewall.

4. Kiedy DHCP Relay jest istotny zamiast serwera DHCP

Sophos Firewall może być nie tylko serwerem DHCP, ale także używać DHCP Relay. W takim przypadku zapytania DHCP od klientów są przekazywane do serwera DHCP w innej sieci.

Jest to szczególnie istotne, gdy adresy IP są centralnie przydzielane przez serwer DHCP Windows lub inny dedykowany system DHCP. W takich projektach opcje DHCP są zazwyczaj utrzymywane na tym centralnym serwerze DHCP, a nie na Sophos Firewall.

W przypadku relay agent wybrany interfejs musi znajdować się w podsieci klientów DHCP. Interfejs właściwego serwera DHCP nie może być używany jako interfejs relay, w przeciwnym razie firewall nie przekaże zapytań klientów zgodnie z oczekiwaniem.

W relay agent można skonfigurować maksymalnie osiem serwerów DHCP. Firewall przekazuje zapytanie klienta do tych serwerów, a klient używa pierwszej oferty, którą otrzyma. Dlatego wiele celów relay powinno spójnie dostarczać ten sam scope i te same opcje DHCP.

W projektach VPN, XFRM, RED lub oddziałów należy najpierw sprawdzić:

• Czy Sophos Firewall ma samodzielnie rozdzielać dzierżawy?
• Czy ma tylko przekazywać zapytania DHCP?
• Czy klient znajduje się w bezpośrednio podłączonej sieci?
• Czy istnieje wiele serwerów DHCP, które mogą przypadkowo odpowiedzieć temu samemu klientowi?

Jeśli odpowiada niewłaściwy serwer DHCP, nawet najpoprawniejsza opcja DHCP na Sophos Firewall nie pomoże.

Przy DHCP Relay przez VPN route-based ważny jest jeszcze jeden punkt: relay agent konfiguruje się w lokalizacji klientów. W centrali potrzebna jest odpowiednia przychodząca reguła firewall dla ruchu DHCP, natomiast ruch relay na firewallu oddziału jest traktowany jako ruch generowany przez system.

5. Kiedy CLI jest nadal przydatne

Dla aktualnych standardowych konfiguracji zazwyczaj wystarcza WebAdmin. CLI jest bardziej przydatne, gdy:

• starszy artykuł lub runbook opiera się już na poleceniach CLI
• trzeba przetestować nietypowe opcje dostawcy
• w przypadku wsparcia chce się dokładnie zobaczyć, jakie powiązania są wewnętrznie zapisane
• środowisko zostało przejęte z bardzo starej wersji SFOS
• trzeba odtworzyć lub skontrolować polecenie z dokumentacji

Kto musi iść tą drogą, powinien najpierw sprawdzić instrukcję Łączenie się z Sophos Firewall przez SSH. Po zalogowaniu się używa się 4. Device Console dla następujących poleceń.

Podstawowa zasada CLI: Definiowanie i wiązanie opcji

W konfiguracji CLI są dwa kroki:

1. Opcja DHCP jest definiowana.
2. Opcja jest wiązana z serwerem DHCP i otrzymuje tam wartość.

Najpierw definiuje się opcję:

system dhcp dhcp-options add optioncode optionname optiontype

Zastępniki oznaczają:

• optioncode: numeryczny kod opcji DHCP
• optionname: dowolnie wybrana nazwa opcji
• optiontype: typ danych, na przykład ipaddress lub string

Przykład dla adresu IP jako opcji DHCP:

system dhcp dhcp-options add optioncode 234 optionname dhcp_magic_ip optiontype ipaddress

Następnie opcja jest wiązana z serwerem DHCP:

system dhcp dhcp-options binding add dhcpname optionname(234) value

Zastępniki oznaczają:

• dhcpname: nazwa serwera DHCP z konfiguracji Sophos Firewall
• optionname(234): nazwa wcześniej zdefiniowanej opcji wraz z kodem opcji w nawiasach
• value: wartość, która ma być dystrybuowana do klientów

Przykład:

system dhcp dhcp-options binding add dhcpname dhcp_red_avanet optionname dhcp_magic_ip(234) value 10.10.10.12

6. Przykłady CLI

Poniższe przykłady są nadal przydatnymi szablonami, gdy opcja musi być ustawiona za pomocą Device Console lub trzeba odtworzyć stary runbook. Te polecenia nie są błędne, po prostu w aktualnych standardowych środowiskach nie są już pierwszym wyborem.

Serwer Thin Client

Za pomocą tej opcji Thin Client jest informowany, na którym serwerze znajduje się obraz lub komponent zarządzania:

system dhcp dhcp-options add optioncode 161 optionname ThinClientServer optiontype ipaddress
system dhcp dhcp-options binding add dhcpname DHCP_Server_Avanet_LAN optionname ThinClientServer(161) value '10.10.10.12'

Jeśli dodatkowo potrzebny jest port, można go ustawić jako string:

system dhcp dhcp-options add optioncode 192 optionname ThinClientServerPort optiontype string
system dhcp dhcp-options binding add dhcpname DHCP_Server_Avanet_LAN optionname ThinClientServerPort(192) value '443'

WDS i PXE

Wartość opcji DHCP dla serwera WDS lub TFTP można ustawić w ten sposób:

system dhcp dhcp-options binding add dhcpname Home_Scope optionname TFTP_Server_Name(66) value 172.16.16.11

Nazwa pliku startowego dla środowiska pre-boot jest przekazywana jako opcja 67:

system dhcp dhcp-options binding add dhcpname Home_Scope optionname Bootfile_Name(67) value \boot\x64\wdsnbp.com

Środowisko pre-boot to środowisko startowe, z którym klient uruchamia się podczas instalacji lub przywracania. W zależności od środowiska potrzebna ścieżka może się różnić, szczególnie w przypadku klientów UEFI, BIOS, 32-bitowych i 64-bitowych.

Wyświetlanie istniejących opcji

Przed zmianami należy wyświetlić istniejące opcje:

system dhcp dhcp-options list

Lista nie pokazuje jednak pełnej granicy tego, co obsługuje SFOS. Sophos dokumentuje, że firewall obsługuje wszystkie obiekty opcji DHCP od 1 do 255, podczas gdy lista CLI pokazuje tylko opcje od 1 do 76. Własne lub specyficzne dla producenta opcje poza tym widokiem mogą więc nadal być poprawne.

Wyświetlanie powiązań serwera DHCP:

system dhcp dhcp-options binding show dhcpname DHCP_Server_Avanet_LAN

Opcję można usunąć w razie potrzeby:

system dhcp dhcp-options delete optionname dhcp_magic_ip(234)

7. Typowe źródła błędów

Jeśli opcja DHCP jest zapisana, ale nie działa na kliencie zgodnie z oczekiwaniami, często wynika to z jednego z tych punktów:

• Niewłaściwy serwer DHCP odpowiada na zapytanie.
• Edytowano niewłaściwy zakres lub interfejs.
• Typ danych nie pasuje do oczekiwanej wartości.
• Adres IP, FQDN, port lub ścieżka są błędnie wpisane.
• Ścieżka pliku startowego nie pasuje do architektury klienta.
• Klient oczekuje stringu, ale opcja została ustawiona jako adres IP.
• Producent używa opcji specyficznych dla dostawcy, które wymagają dodatkowych parametrów.
• Dzierżawa nie została odnowiona po zmianie.
• Używany jest przekaźnik DHCP, mimo że opcja została utrzymywana na Sophos Firewall.

Po zmianie należy odnowić dzierżawę na kliencie testowym i sprawdzić, czy klient rzeczywiście otrzymuje oczekiwane opcje. Jeśli zachowanie nadal nie pasuje, zrzut pakietów często jest szybszy niż długie zgadywanie: w pakietach DHCP widać, który serwer odpowiada i jakie opcje są rzeczywiście dostarczane.

8. Testowanie zmiany

Po zapisaniu opcji DHCP nie należy tylko czekać, aż następny klient kiedyś pobierze nową dzierżawę. Lepszy jest kontrolowany test z znanym urządzeniem w dotkniętej sieci.

Sugerowany przebieg:

1. Podłącz klienta testowego do właściwego VLAN lub interfejsu.
2. Odnów starą dzierżawę lub uruchom ponownie klienta.
3. Sprawdź, jakie adresy DHCP, brama, serwery DNS i dodatkowe opcje zostały odebrane.
4. Przetestuj system docelowy, na przykład PXE-Boot, uruchomienie WDS, rejestrację Thin Client lub provisioning telefonu.
5. Sprawdź w WebAdmin, czy dzierżawa pojawia się w oczekiwanym zakresie DHCP.
6. Jeśli wynik nie pasuje, sprawdź za pomocą Packet Capture, który serwer DHCP odpowiada i jakie opcje są zawarte w ofercie lub ACK.

Dla wąskiego zrzutu zazwyczaj wystarczy filtr na UDP 67 i 68 między klientem a serwerem DHCP. Obsługa narzędzia WebAdmin jest opisana w Używanie Packet Capture w WebAdmin Sophos Firewall.

Przy testach PXE i WDS warto dodatkowo udokumentować, czy klient testowy używa BIOS czy UEFI. Wiele problemów z bootowaniem nie wynika z samego DHCP, ale z pliku startowego, który nie pasuje do architektury.

9. Rozwiązywanie problemów według objawów

Jeśli opcje DHCP nie działają, pomocna jest często kontrola zorientowana na objawy, zamiast ponownego tworzenia tej samej opcji.

• Klient nie otrzymuje adresu IP: Serwer DHCP, VLAN, interfejs albo relay nie pasują. Sprawdź listę lease, interfejs, VLAN i DHCP Relay.
• Klient otrzymuje IP, ale bez opcji: Odpowiada zły zakres lub zły serwer DHCP. Sprawdź DHCP offer lub ACK w Packet Capture.
• PXE znajduje serwer, ale nie startuje: Opcja 67, ścieżka pliku albo architektura nie pasuje. Sprawdź bootfile BIOS/UEFI oraz log TFTP/WDS.
• Thin client się nie łączy: Zły kod opcji, typ albo wartość producenta. Porównaj dokumentację producenta i dostarczoną wartość.
• Zmiana działa dopiero później: Klient używa starego lease. Odnów lease, uruchom klienta ponownie albo uwzględnij lease time.
• Polecenie CLI nie działa: Nazwa DHCP, nazwa opcji albo notacja nawiasów jest błędna. Sprawdź system dhcp dhcp-options list i wynik bindingu.

Jeśli w zrzucie odpowiada inny serwer DHCP, najpierw należy wyjaśnić projekt sieci. Dwa serwery DHCP w tej samej domenie rozgłoszeniowej są klasyczną przyczyną zmiennego zachowania. W przypadku bardziej złożonych pytań dotyczących VLAN, mostków lub interfejsów pomocne jest Planowanie i konfigurowanie stref i interfejsów Sophos Firewall.

Często zadawane pytania