Przejdz do tresci
Avanet

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

  1. Otworzyć Network > DHCP.
  2. W sekcji Server kliknąć Add.
  3. Wpisać jednoznaczną nazwę, na przykład dhcp-vlan20-clients.
  4. W polu Interface wybrać interfejs klientów VLAN20 - 10.20.0.1.
  5. W sekcji Dynamic IP lease dodać pulę od 10.20.0.100 do 10.20.0.199.
  6. W polu Subnet mask wpisać 255.255.255.0 dla przykładowej sieci /24.
  7. Włączyć Use interface IP as gateway. Klienci otrzymają wtedy 10.20.0.1 jako Gateway.
  8. Ustawić serwery DNS, Domain name i czasy dzierżawy odpowiednio do sieci.
  9. W razie potrzeby dodać statyczne przypisania MAC-IP.
  10. 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 zalogować się przez SSH i odczytać bieżącą metodę oraz zakres w Device Console:

system dhcp conf-generation-method show
system dhcp static-entry-scope show

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.

Udokumentowane wartości domyślne to old i network. Gdy adresy MAC są przypisane więcej niż raz, stara metoda może podawać nieprawidłowe informacje, takie jak serwery DNS lub brama. Nie należy nadpisywać już zmienionego stanu. Podczas wycofywania zmiany należy użyć dokładnie wcześniej odczytanych wartości; tylko przy potwierdzonym stanie domyślnym są to system dhcp static-entry-scope network i system dhcp conf-generation-method old. Następnie każdy objęty zakres trzeba przetestować 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.

⚠️ W klastrze HA Sophos obsługuje usługę DHCP w trybie Active-passive, ale nie w trybie Active-active. Trzeba to uwzględnić przed uruchomieniem; zmiana trybu HA nie jest krokiem diagnostycznym dla pojedynczego zakresu.

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ń:

ipconfig /release
ipconfig /renew
ipconfig /all

⚠️ 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.

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:

  1. Klient otrzymuje adres z właściwej puli.
  2. Brama i serwery DNS są zgodne z planem.
  3. Brama jest osiągalna.
  4. Nazwy wewnętrzne i zewnętrzne są rozwiązywane.
  5. 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ę:

  1. Udokumentować pulę, opcje, przypisania statyczne i aktywne dzierżawy dotychczasowego serwera.
  2. Odpowiednio wcześnie skrócić czas dzierżawy na starym serwerze i poczekać, aż aktywni klienci odnowią dzierżawę z krótszą wartością.
  3. Zatrzymać dotychczasowy serwer i początkowo uruchomić nowy serwer z niepokrywającą się pulą przejściową.
  4. Odnowić dzierżawy na kilku różnych klientach oraz sprawdzić bramę, DNS i osiągalność.
  5. 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.

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 dotyczą całej usługi DHCP. Najpierw należy odczytać ich stan:

system dhcp one-lease-per-client show
system dhcp send-dhcp-nak show

one-lease-per-client jest domyślnie wyłączone. Aktualna pomoc nie wyjaśnia, jak funkcja identyfikuje klienta we wszystkich przypadkach szczególnych. Włączenie działa globalnie, 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 zmiennymi adresami MAC.

send-dhcp-nak jest domyślnie włączony. DHCPNAK odrzuca adres, którego serwer nie akceptuje, i kieruje klienta z powrotem do negocjacji DHCP. Wyłączenie może wydłużyć nieprawidłowy stan klienta i nie jest ogólną naprawą nieudanych dzierżaw.

Przełączniki zmienia się następująco:

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

Nawiasy kwadratowe są symbolami zastępczymi; należy użyć tylko wymaganej wartości. Po zmianie trzeba ponownie sprawdzić wartość poleceniem show, odnowić dzierżawę, skontrolować IPv4 lease i w razie potrzeby przechwycić ruch UDP 67/68. Dla potwierdzonych wartości domyślnych wycofanie zmiany wymaga system dhcp one-lease-per-client disable albo system dhcp send-dhcp-nak enable. Jeżeli stan początkowy był niestandardowy, należy przywrócić dokładnie wartości odczytane poleceniem show przed zmianą i ponownie sprawdzić oba ustawienia.