Konfiguracja i test DHCP Relay w Sophos Firewall

DHCP Relay przekazuje żądania DHCP z sieci klientów do serwera w innej sieci. Na Sophos Firewall otwiera się Network > DHCP, tworzy w sekcji Relay agenta dla interfejsu klientów i wprowadza adres IP serwera DHCP.

Skrócona procedura: wybrać interfejs klientów, wprowadzić serwer DHCP, sprawdzić na serwerze właściwy zakres i trasę zwrotną, odnowić dzierżawę i zarejestrować wymianę filtrem port 67 or port 68. Relay through IPsec włącza się tylko dla policy-based IPsec, a nie dla VPN route-based. W przypadku VPN route-based należy najpierw wyjaśnić z Sophos Support opisane poniżej rozbieżności w źródłach oraz obsługę tej konfiguracji w konkretnym buildzie; skrócona procedura nie stanowi potwierdzenia dopuszczalności takiego układu.

W przykładzie użyto sieci klientów 10.20.0.0/24, interfejsu relay 10.20.0.1 oraz serwera DHCP 172.16.16.17. Jest to przykład dla IPv4: wszystkie adresy, interfejs klientów i nazwę należy dostosować do własnej sieci. Zakres obejmuje pulę adresów wraz z parametrami sieci, z której serwer przydziela dzierżawy. Brama musi znajdować się w sieci klientów i być osiągalna; serwer DNS musi być osiągalny z klienta. Przed zmianą wykonać kopię istniejących zakresów, agentów relay i tras oraz użyć klienta testowego, który pobiera adresy automatycznie przez DHCP.

Wymagania i ograniczenia

Serwer DHCP musi mieć zakres dla 10.20.0.0/24. Sophos Firewall nie przydziela dzierżawy samodzielnie, lecz używa adresu interfejsu relay, aby serwer wybrał właściwy zakres.

Relay potrzebuje trasy do serwera, a serwer trasy zwrotnej do 10.20.0.1.

Jeżeli zapora ma zamiast tego przydzielać adresy bezpośrednio w podłączonej sieci klientów, odpowiedni jest artykuł Konfiguracja Sophos Firewall jako serwera DHCP. Opcje DHCP konfiguruje się na serwerze, który przydziela dzierżawę.

Serwer DHCPv4 i relay mogą działać również na tej samej Sophos Firewall:

• Serwer nasłuchuje na innym interfejsie.
• Opcja Accept client request via relay jest włączona.
• Dla każdej podsieci klientów istnieje osobny zakres serwera z odpowiednią pulą dzierżaw, maską podsieci, bramą i DNS.

Agent relay używa odpowiedniego interfejsu klientów, a jako adresu docelowego — adresu interfejsu serwera. Klienci w podsieci serwera nadal otrzymują adresy bezpośrednio, bez relay.

Serwer DHCPv6 i DHCPv6 Relay nie mogą być aktywne jednocześnie. Jeśli zapora ma samodzielnie przydzielać adresy IPv6, artykuł Konfigurowanie serwera DHCPv6 na Sophos Firewall opisuje osobną procedurę obejmującą Router Advertisement, DUID i kontrolę dzierżawy.

Konfiguracja podlega następującym ograniczeniom:

• Interfejs relay znajduje się w tej samej podsieci co klienci i nie może być interfejsem serwera DHCP.
• Agentów relay można tworzyć na interfejsach fizycznych i wirtualnych, takich jak VLAN, Wireless lub Bridge, ale nie na Interface Alias.
• W podsieci serwera DHCP nie tworzy się agenta relay.
• Dla każdej podsieci klientów tworzy się oddzielnego agenta relay.
• Dla jednego agenta relay można skonfigurować maksymalnie osiem serwerów DHCP. Żądanie trafia do wszystkich, a klient korzysta z pierwszego Offer.
• Serwer DHCPv4 i DHCPv4 Relay mogą działać jednocześnie na tej samej zaporze, ale nie na tym samym interfejsie.
• Serwer DHCPv6 i DHCPv6 Relay nie mogą być jednocześnie aktywne na tej samej zaporze.
• Między klientem a relay wymagane są porty UDP 67 i 68; relay i serwer komunikują się przez UDP 67. Serwer musi mieć trasę zwrotną do adresu IP relay 10.20.0.1.

Wiele celów relay powinno dostarczać temu samemu klientowi spójne parametry sieciowe i opcje, ale przydzielanie adresów musi być skoordynowane (mechanizm failover serwerów zgodnie z dokumentacją serwera) albo dynamiczne zakresy przydzielania adresów muszą być rozłączne. W przeciwnym razie różne odpowiedzi powodują zachowanie trudne do odtworzenia.

Konfiguracja DHCP Relay bez VPN

1. Otworzyć Network > DHCP.
2. W sekcji Relay kliknąć Add.
3. Wprowadzić jednoznaczną nazwę, na przykład relay-clients-vlan20.
4. Dla tego przykładu w polu IP version wybrać IPv4. Dla IPv6 nie używać adresów IPv4 ani portów UDP z tej instrukcji.
5. W polu Interface wybrać interfejs klientów VLAN20 - 10.20.0.1.
6. W polu DHCP server IP wprowadzić serwer 172.16.16.17, dodać go do listy przyciskiem plus i sprawdzić, czy jest na niej widoczny.
7. Pozostawić Relay through IPsec wyłączone i zapisać.

Następnie odnowić dzierżawę na kliencie testowym. Żądania relay są ruchem generowanym przez system, więc ta procedura nie wymaga osobnej reguły na zaporze relay. Urządzenia między relay a serwerem muszą jednak zezwalać na UDP 67 w obu kierunkach; segment klientów używa UDP 67/68. Jeśli klient nie otrzyma adresu, najpierw sprawdzić, czy serwer ma zakres dla 10.20.0.0/24 i zna trasę do interfejsu relay. W przypadku problemów z VLAN pomaga Konfiguracja interfejsu VLAN w Sophos Firewall.

XML API: tożsamość obiektu i ograniczenie walidacji IPv6

Przy automatyzacji ta sama konfiguracja należy do obiektu DHCPRelay: Name określa agenta relay, Interface — interfejs klientów, IPFamily — świadomie wybraną rodzinę IPv4 lub IPv6, a DHCPServerIP — listę serwerów. Dokumentacja dodawania i edycji dla SFOS 22 i 23 oznacza te cztery pola jako wymagane; udokumentowana wartość domyślna dla IPFamily to IPv4. Pole DHCPServerIP opisano jako ARRAY z typami IPADDRESS i IPADDRESS6: dozwolonych jest wiele wartości, duplikaty są ignorowane, a LINKLOCAL jest wykluczone. Nadal można więc używać wielu celów relay; pojedyncze pole z wartością zastępczą w przykładzie nie potwierdza ani sposobu serializacji listy, ani kodowania IPv6. Należy świadomie zachować stan opcji Relay through IPsec odpowiedni dla wariantu VPN opisanego poniżej, a nie wywodzić go z przykładu API.

Tabela parametrów podaje jednocześnie dla DHCPServerIP maksymalną długość 15 znaków. Nie odpowiada to ogólnie dozwolonemu zapisowi adresów IPv6 typu IPADDRESS6: dokumentacja jest w tym miejscu niespójna i nie potwierdza, jak walidator konkretnego buildu przetwarza IPv6. Nie wynika z tego ani brak obsługi DHCPv6 Relay w produkcie, ani alternatywne kodowanie, ani możliwość skracania adresów.

Dla IPv6 należy najpierw użyć ręcznej konfiguracji w WebAdmin, a przed automatyzacją IPv6 wyjaśnić z Sophos Support schemat, walidację adresów i format listy serwerów dla dokładnej wersji oraz buildu SFOS. Zapisana konfiguracja w GUI ani pomyślnie uzyskana dzierżawa klienta nie potwierdzają poprawności żądania XML dla IPv6. Opisane poniżej kontrole klienta i przepływu pakietów oraz wycofanie zmian z uwzględnieniem wcześniejszego stanu nadal są wymagane; adresów IPv4 i portów UDP z tego przykładu nie należy przenosić do konfiguracji IPv6.

Zmiana interwału odświeżania Relay tylko w uzasadnionym przypadku

Device Console wyświetla globalny interwał pakietów odświeżania DHCP Relay za pomocą:

system dhcp dhcp-relay-refresh-interval show

Udokumentowana wartość domyślna wynosi 10 sekund. Sophos podaje na tej samej stronie SFOS 22 dwie różne górne granice: składnia pokazuje 10000, a opis opcji 1000 sekund. Nie należy używać wartości powyżej 1000 wyłącznie na podstawie wiersza składni. Każdą wyjątkową potrzebę trzeba najpierw skonsultować z Sophos Support.

Zmiana korzysta z następującego szablonu:

system dhcp dhcp-relay-refresh-interval set seconds <seconds>

Symbol zastępczy należy zastąpić zweryfikowaną wartością. Interwału nie zmienia się jako ogólnego tuningu; nie naprawia on brakującego scope serwera, routingu, IPsec ani reguł firewalla. Najpierw zapisać bieżącą wartość, a następnie użyć show, uzyskać nową dzierżawę klienta i sprawdzić przepływ UDP 67/68. Rollback przywraca wcześniej odczytaną wartość.

DHCP Relay przez route-based IPsec

Pomoc dla SFOS 22 i SFOS 23 opisuje DHCP Relay przez XFRM do zewnętrznego serwera DHCP za centralną zaporą. Opisany układ wykorzystuje tunel route-based Any-to-Any. Wariant route-based z Traffic Selectors nie jest potwierdzony dla tej procedury.

⚠️ Oficjalna pomoc dla SFOS 22 i SFOS 23 jest sprzeczna: zarówno przegląd DHCP, jak i Routing and NAT for IPsec tunnels wykluczają DHCP Relay przez VPN route-based. Natomiast Add a DHCP relay i osobna instrukcja dla route-based opisują poniższy układ Any-to-Any. Nie można na tej podstawie uznać obsługi tej konfiguracji przez produkt za potwierdzoną. Jeśli pola różnią się od opisanych, nie zastępować ich opcjami policy-based, lecz wyjaśnić topologię i konkretny build z Sophos Support.

⚠️ Sprzeczność między źródłami pozostaje nierozstrzygnięta; projekt jest udokumentowany, ale nie został potwierdzony ani przetestowany jako możliwość produktu. Przed wdrożeniem Sophos Support musi wyjaśnić obsługę dokładnego buildu SFOS oraz topologii Any-to-Any z zewnętrznym serwerem DHCP. Takie potwierdzenie jest warunkiem wstępnym, a nie dowodem już dostępnym w tym artykule. Do czasu wyjaśnienia nie wprowadzać zmian konfiguracji route-based według tej procedury.

Udokumentowany układ wymaga spełnienia poniższych warunków. Do czasu wyjaśnienia z Sophos Support szczegóły służą wyłącznie do planowania; zmiany konfiguracji należy wprowadzać dopiero po potwierdzeniu:

1. Połączenia IPsec Any-to-Any na obu zaporach.
2. Zaadresowane interfejsy XFRM z bramą.
3. Trasy statyczne, SD-WAN lub dynamiczne na obu zaporach: od relay do serwera DHCP oraz dla odpowiedzi z powrotem do adresu IP relay 10.20.0.1.
4. Dozwolony dostęp IPsec w Administration > Device access dla używanych interfejsów WAN.
5. Reguła w centrali z VPN do strefy serwera, z Source 10.20.0.1, Destination 172.16.16.17 i Service DHCP.

W oddziale interfejs klientów zostaje przypisany do agenta relay; Relay through IPsec pozostaje wyłączone. Żądanie relay jest tam ruchem generowanym przez system i nie wymaga osobnej reguły zapory dla DHCP.

Trasa SD-WAN używa:

• Any jako Source,
• hosta 172.16.16.17 jako Destination,
• DHCP jako Service,
• zdalnej bramy XFRM.

W centrali trasa zwrotna z serwera DHCP do adresu IP relay 10.20.0.1 prowadzi przez bramę XFRM.

Aby w razie awarii tunelu ruch ten nie przechodził przez inną bramę, w obu dedykowanych trasach SD-WAN włączyć Route only through specified gateways.

Aby utworzyć dedykowane trasy SD-WAN, po uzyskaniu potwierdzenia:

1. Otworzyć Routing > SD-WAN routes, wybrać IPv4 > Add i nadać jednoznaczną nazwę.
2. W sekcji Link selection settings wybrać Primary and backup gateways.
3. W polu Primary gateway wskazać odpowiednią bramę XFRM danej zapory; następnie zapisać.

Regułę zapory w centrali tworzy się w Rules and policies > Firewall rules > Add firewall rule > New firewall rule z wymienionymi powyżej hostami i usługą.

Destination zone odpowiada rzeczywistej sieci serwera, na przykład DMZ, a nie automatycznie LAN.

Opcja fail-closed zapobiega użyciu trasy alternatywnej, ale oznacza też, że w razie awarii tunelu nie można uzyskać nowych dzierżaw tą ścieżką.

Muszą również istnieć ogólne reguły VPN dla tunelu Any-to-Any. Konfigurację tunelu i tras XFRM szczegółowo opisano w artykule Konfiguracja Site-to-Site IPsec w Sophos Firewall.

⚠️ Ta procedura route-based dotyczy zewnętrznego serwera DHCP za centralną zaporą. Interfejs Sophos Firewall jako centralny serwer DHCP nie jest obsługiwany w tym projekcie.

DHCP Relay przez policy-based IPsec

W przypadku policy-based IPsec w oddziale włącza się Relay through IPsec. Lokalne i zdalne podsieci połączenia IPsec muszą obejmować interfejs relay i serwer DHCP.

Jeśli zewnętrzny serwer DHCP znajduje się za centralną zaporą, potrzebne są tam dwie reguły. Warunkiem jest istniejący, działający tunel.

Jeśli trzeba go dopiero utworzyć, należy zrobić to w Site-to-site VPN > IPsec > IPsec connections > Add z ustawieniem Connection type: Policy-based:

• W oddziale: Gateway type: Initiate the connection.
• W centrali: Respond only.
• Listening interface to na każdej zaporze jej własny interfejs WAN.
• Gateway address to adres WAN drugiej strony.

Ustawienia uwierzytelniania i Preshared key muszą być zgodne; sieci lokalne i zdalne należy zamienić miejscami po drugiej stronie. W przykładzie z zewnętrznym serwerem są to 10.20.0.0/24 i faktycznie używana sieć serwera.

Zezwolić na dostęp IPsec z WAN w Administration > Device access.

W oddziale ruch relay generowany przez system nie wymaga automatycznie utworzonej reguły zapory. W centrali można ograniczyć automatycznie utworzone reguły do wymienionych poniżej hostów DHCP, stref i usług.

Nie usuwać istniejących reguł dla pozostałego ruchu VPN.

• Z VPN do strefy serwera: sieć relay do serwera DHCP, Service DHCP.
• Ze strefy serwera do VPN: serwer DHCP do sieci klientów, Service DHCP.

W udokumentowanej procedurze policy-based adres źródłowy ruchu relay generowanego przez system należy ustawić na adres IP relay za pomocą sys-traffic-nat.

Poniższe polecenia wykonuje się po zalogowaniu przez SSH w Device Console.

Szczegółowa pomoc dotycząca routingu/NAT dla SFOS 22 i 23 rozróżnia ruch przekazywany i ruch generowany przez system: dla tego drugiego dodatkowa system ipsec_route nie jest wymagana. Ogólny przegląd DHCP nadal wymienia natomiast krok dodania trasy IPsec.

Ta rozbieżność nie jest powodem do rutynowego dodawania kolejnej trasy: najpierw sprawdzić istniejącą trasę i przepływ pakietów, a jeśli zachowanie konkretnego buildu odbiega od opisu, skontaktować się z Sophos Support.

NAT nie zastępuje trasy.

• destination pozostaje adresem serwera.
• snatip to adres źródłowy relay, a nie adres serwera.
• Zwykła reguła WAN-MASQ nie zastępuje sys-traffic-nat.

Przed zmianą zapisać bieżący stan:

show advanced-firewall

⚠️ sys-traffic-nat add zmienia globalną konfigurację NAT dla ruchu generowanego przez system. Destination i adres źródłowy muszą pasować do tunelu IPsec i trasy zwrotnej.

W przykładzie adres źródłowy interfejsu relay jest przypisywany dla ruchu do serwera DHCP:

set advanced-firewall sys-traffic-nat add destination 172.16.16.17 snatip 10.20.0.1

Następnie ponownie wykonać show advanced-firewall i sprawdzić, czy istnieje dokładnie ten wpis. Serwer musi móc osiągnąć 10.20.0.1 przez tunel. Jeśli ten sam wpis istniał przed zmianą, nie należy do rollbacku tej procedury.

Rollback wpisu utworzonego w tej procedurze:

set advanced-firewall sys-traffic-nat delete destination 172.16.16.17 snatip 10.20.0.1

Inne przypadki routingu policy-based i procedury dla starszych wersji SFOS wyjaśnia artykuł Tworzenie trasy IPsec w Sophos Firewall.

Gdy centrala sama jest serwerem DHCP

Tylko w tym scenariuszu policy-based, w którym Sophos Firewall w centrali sam jest serwerem DHCP, pozostawić Create firewall rule niezaznaczone w połączeniach IPsec na obu zaporach. Komunikacja DHCP z serwerem działającym na zaporze nie jest tym samym co przekazywanie ruchu do serwera zewnętrznego; opisane wcześniej reguły przekazywania w centrali dotyczą scenariusza z serwerem zewnętrznym. Zachować dostęp IPsec z WAN w Administration > Device access oraz reguły wymagane dla pozostałego ruchu użytkowników VPN.

Jeżeli centralna Sophos Firewall przy policy-based IPsec sama działa jako serwer DHCP, w Network > DHCP > Server tworzy się lub edytuje zakres serwera.

1. Włączyć Accept client request via relay.
2. Wprowadzić pulę dzierżaw z 10.20.0.0/24 i ustawić 10.20.0.1 jako bramę.
3. W agencie relay jako DHCP server IP wprowadzić adres interfejsu serwera centralnej zapory; w poprzednim przykładzie NAT jej adres zastępuje odpowiednio 172.16.16.17.

Przykład dla Dynamic IP lease, który należy dostosować, to 10.20.0.10 do 10.20.0.30 z maską podsieci 255.255.255.0. Brama 10.20.0.1 i stałe adresy infrastruktury pozostają poza pulą.

Pulę dobrać do liczby klientów i już zarezerwowanych adresów. Use device’s DNS settings używać tylko wtedy, gdy zapisane tam serwery DNS są osiągalne z oddziału.

Dla tego serwera działającego na zaporze selektory policy-based w centrali obejmują adres interfejsu serwera i sieć klientów; w oddziale obowiązuje odwrotne przypisanie.

⚠️ Sprawdzić wersję przed zmianą globalną: Poniższa procedura włączenia dotyczy wyłącznie udokumentowanego scenariusza SFOS 22. Dostępne strony pomocy SFOS 23 są sprzeczne: HO firewall as DHCP server and BO firewall as relay agent opisuje dzierżawy DHCP przez IPsec jako domyślnie włączone i niewymagające dodatkowej konfiguracji; przegląd DHCP nadal nakazuje włączenie przez CLI. Sprzeczność pozostaje nierozstrzygnięta. Nie potwierdza ona rzeczywistego stanu po aktualizacji ani nie dowodzi usunięcia polecenia. W SFOS 23 nie włączać rutynowo ustawienia globalnego: zapisać dokładny build i bieżący stan, a następnie najpierw potwierdzić z Sophos Support, czy zmiana jest potrzebna. Jeśli stan jest niejasny lub polecenie odczytu stanu jest niedostępne, zatrzymać się przed wprowadzaniem zmian.

Zanotować dokładny build SFOS, a przed każdą zmianą wyświetlić i zapisać bieżący stan w Device Console centralnej zapory przydzielającej dzierżawy:

system dhcp lease-over-IPSec show

⚠️ Poniższe ustawienie działa globalnie dla dzierżaw DHCP przez IPsec. Włączyć je tylko na zaporze, która sama przydziela dzierżawy. Zanotować wyświetlony stan początkowy, aby rollback nie wyłączył istniejącej wcześniej konfiguracji.

Tylko w SFOS 22, jeśli zapisany stan to wyłączony, włączyć i następnie sprawdzić poprzednim poleceniem show. Jeśli funkcja jest już włączona, niczego nie zmieniać:

system dhcp lease-over-IPSec enable

Tylko jeśli funkcja była wcześniej wyłączona na centralnej zaporze przydzielającej dzierżawy i została faktycznie włączona podczas autoryzowanej procedury, rollback to:

system dhcp lease-over-IPSec disable

Jeśli funkcja była już włączona, należy pozostawić ją włączoną. W obu przypadkach system dhcp lease-over-IPSec show potwierdza przywrócony stan.

Test działania i rozwiązywanie problemów

Sam zapisany agent relay nie potwierdza poprawnego działania konfiguracji. Na kliencie testowym odnowić dzierżawę, a w Diagnostics > Packet capture > Configure ustawić w polu Enter BPF string wąski filtr:

port 67 or port 68

W przepływie pakietów powinny być kolejno widoczne:

1. Żądanie klienta.
2. Przekazane żądanie.
3. Offer serwera.
4. Droga powrotna.

Kolumny In interface, Out interface, Source IP, Destination IP, Ports [src, dst] i Status pokazują, na którym etapie wymiana się kończy.

Pakiety relay mogą być oznaczone jako Generated lub Forwarded. Przy Violation pole Reason wskazuje, co sprawdzić dalej.

Obsługę i pola opisuje artykuł Packet Capture w Sophos Firewall WebAdmin.

Sam Offer nie wystarcza: klient musi zażądać adresu i otrzymać ACK. Następnie:

• Sprawdzić na kliencie adres IP z przewidzianej puli, maskę podsieci, bramę i DNS.
• Skontrolować wpis dzierżawy na serwerze, który ją przydzielił.

Odpowiedź serwera na ping nie potwierdza ani osiągalności przez UDP, ani udanej wymiany DHCP.

Te kontrole musi wykonać administrator.

Typowe błędy można zawęzić w następujący sposób:

• Nie widać żądania klienta: sprawdzić VLAN, port przełącznika, interfejs klientów lub lokalnego klienta DHCP.
• Żądanie dociera do zapory, ale nie jest przekazywane: sprawdzić interfejs relay, adres IP serwera, trasę oraz — w przypadku policy-based IPsec — Relay through IPsec.
• Serwer otrzymuje żądanie, ale nie odpowiada: sprawdzić zakres dla podsieci relay, autoryzację serwera i lokalną zaporę serwera.
• Offer dociera do centrali, ale nie do klienta: sprawdzić trasę zwrotną, reguły centralnej zapory, podsieci IPsec i wpis NAT.
• Klient otrzymuje błędną konfigurację: ustalić, który serwer odpowiada jako pierwszy, i porównać zakresy oraz opcje DHCP na wszystkich serwerach docelowych relay.
• Policy rule denied przy Source 0.0.0.0: klient bez adresu rozpoczyna komunikację z tym adresem źródłowym. Sprawdzić, czy na właściwym interfejsie klientów działa odpowiedni serwer DHCP lub relay; nie tworzyć ogólnej reguły Allow dla 0.0.0.0 ani Any, aby zamaskować objaw. Przegląd opisuje odrzucenie przy braku serwera; w scenariuszu relay sprawdzić rzeczywistą ścieżkę pakietów, zamiast wyciągać z tego wniosek o ogólnej blokadzie relay.

Wycofanie konfiguracji

Przed planowanym rollbackiem najpierw upewnić się, że klienci mogą osiągnąć inny serwer DHCP. Następnie usunąć agenta relay w Network > DHCP > Relay. Dedykowane trasy, obiekty hostów i reguły usuwać dopiero wtedy, gdy Packet Capture nie pokazuje już żądań relay; zachować obiekty współdzielone z innym ruchem VPN. Przy IPsec policy-based dodatkowo usunąć tylko wpis sys-traffic-nat utworzony w tej procedurze. Przywrócić lease-over-IPSec wyłącznie na centralnej zaporze, która sama przydziela dzierżawy, i tylko jeśli stan został faktycznie zmieniony podczas autoryzowanej procedury; odtworzyć wcześniej zanotowany stan. Nie jest to część rollbacku relay do zewnętrznego serwera DHCP ani stanu, który nie został zmieniony.

Często zadawane pytania