Podkast 22T9 Instalacja serwera DHCP na Ubuntu Server [Konfiguracja]
Więcej miejsc do posłuchania:
WERSJA TEKSTOWA
Cześć, witam Cię w dzisiejszym odcinku mojego podcastu. Dzisiaj temat serwer DHCP na serwerze LINUX. Plusy i minusy. Jeżeli chodzi o stosowanie serwera DHCP to zalecane jest stosowanie centralnego serwera. Nawet w przypadku małej sieci mamy dwie opcje. Centralny serwer na naszym routerze lub parze routerów, bądź centralny serwer odseparowany. Najczęściej, gdy mówimy o serwerach DHCP to mówimy o środowiskach, które mają domenę. Nie jest to konieczne ani bezpośrednio związane. Natomiast w całkiem malutkich środowiskach, gdzie domeny nie potrzebujemy to prawdopodobnie serwer na routerze nam zupełnie wystarczy. Jeżeli środowisko jest trochę większe i mamy tą domenę to najczęściej widzę, że klienci korzystają z serwera w oparciu o Microsoft i część rozwiązania domenowego.
To rozwiązanie nie jest jakieś najlepsze z możliwych. Najczęściej jest używane, bo jest gotowe. Jest częścią całego systemu serwerowego i można uruchomić je w trybie wysokiej dostępności. Natomiast co do praktyki działania tego typu systemów to raczej widzę, że Microsoft mógłby sporo tutaj poprawić w zakresie działania swojego serwera DHCP.
Jako alternatywy możemy użyć też rozwiązania open source. Jest ich kilka. Jeśli mówimy o takim najpopularniejszym to jest ono dostępne w ramach pakietu m.in. serwera Ubuntu ale możesz uruchomić na dowolnym serwerze Linuxowym, jaki posiadasz. Z funkcjonalnego punktu widzenia ważne jest to, czy chcesz mieć replikację informacji o dzierżawach. Tzn jak mamy jeden serwer DHCP to tutaj sprawa jest jasna i oczywista, on ma swoją tablicę mapowań jakie adresy rozdał jakim hostom. Natomiast w przypadku, gdy chcemy zapewnić wysoką dostępność to dobrze by było, aby był drugi serwer DHCP i żeby ta informacja była replikowana. Jeśli zostanie nam wyłączony, uszkodzony serwer pierwszy to ten drugi serwer będzie wiedział, jakie adresy zostały przydzielone.
Czy jest to konieczne i niezbędne? Nie jest, można darować sobie tą replikacje. Tyle tylko, że jeśli chodzi o zagrożenie, zwłaszcza jak mamy większą sieć, na wielu podsieciach to może wystąpić taka sytuacja, że po takiej awarii serwera DHCP podepnie nam się nowy host w danej sieci i ten serwer DHCP nie mający żadnego wskazania, żadnej historii jakie adresy zostały przypisane i są zajęte – przypisze już adres wcześniej przypisany. Efekt jest prosty. Mamy konflikt adresacji IP w danej podsieci.
Scenariusz jest taki, że jeżeli w ogóle się zdarza taka awaria to raczej rzadko. Więc pytanie jak duże jest ryzyko pojawienia się takiej korelacji pomiędzy zdarzeniem wyłączenia serwera podstawowego DHCP a przypisaniem tego samego adresu IP dla hosta. Jest to również skorelowane z czasem dzierżawy. Mamy możliwość na każdym serwerze DHCP (przynajmniej bardziej zaawansowanym) skonfigurowania na jak długi okres przyznajemy adres IP. Jeśli ten adres jest przyznany i wydzierżawiony na krótko, np na godzinę, to szansa, że nam się pojawi taki konflikt automatycznie maleje a potencjalnie rośnie obciążenie tego serwera więc w zależności od tego, jakie mamy duże środowisko można taką sytuację zignorować lub ją zaplanować.
W przypadku dużego środowiska, chcemy mieć HA, mamy dwie serwerownie, najlepiej jednak tą replikacje wykonać, dlatego, że najczęściej w takich wielkich środowiskach konfigurujemy DHCP Relay. Możemy mieć na takim serwerze 1000, 1500, 2000, 10 000, w zależności od wielkości środowiska. Na takim serwerze centralnym, gdy mamy różne podsieci, konfigurujemy najczęściej też pulę adresów. Możemy przypisać jakie zakresy zwracanej informacji DHCP, czyli IP adres hosta, maska dla danej podsieci i gateway jest wysyłany do hosta końcowego, DNS. Możemy oczywiście tą konfigurację różnicować, w zależności od podsieci. Aby dowiedzieć się o tym, z jakiej podsieci przychodzi zapytanie (domyślnie przychodzi z podsieci L2 broadcastem, natomiast nie może nam wszystko nim przychodzić w przypadku centralnego serwera), najczęściej Broadcast jest zamieniany przez DHCP Relaya na Unicast i wysyłany do naszego serwera centralnego. Serwer ten wiedząc z jakiej sieci pochodzi zapytanie, jest w stanie nam przypisać odpowiedni adres IP z puli, w której jest powiązany z daną podsiecią.
Mamy możliwość jednocześnie centralizowania informacji o adresacji utrzymując skalowalność całego rozwiązania i centralną informację o tym, co, gdzie jest przypięte. Jeśli chciałbyś zobaczyć, jak konfiguruje się taki przykładowy serwer, to w najbliższym poniedziałkowym odcinku będziesz mógł zobaczyć taką konfigurację. W przypadku pytań, pisz w komentarzu. Dziękuje Ci za dziś i do usłyszenia już za tydzień 🙂






