Dnsmasq – DHCP i DNS dla małych i średnich sieci i nie tylko.

DHCP od ISC, którego opis konfiguracji zamieszczono niedawno na jakilinux.org jest świetny, popularny, skalowalny, o bardzo szerokich możliwościach, ale… jest też stosunkowo skomplikowany, szczególnie dla kogoś, kto po prostu chce nadawać adresy w swojej sieci. Nie jest to jednak jedyna implementacja opensource’owego serwera DHCP. Do godnych uwagi rozwiązań należy dnsmasq, czyli prosty i lekki serwer DHCP oraz forwarder DNS (de facto – DNS cache’ujący). Na dodatek obsługujący IPv6 (tylko dla DNS). Klient TFTP gratis. Co prawda tylko read only, ale do bootowania po sieci z użyciem PXE wystarczy, poza tym, to celowy zabieg w założeniu zwiększający bezpieczeństwo.

Co prawda na stronie projektu wspomina się o działaniu dnsmasq nawet na 1000 hostach, ale osobiście odradzam – cache DNS nie jest specjalnie pojemny (limit w kodzie, poza tym, co można skonfigurować) i przy większej ilości zapytań demon nie wyrobi się z odpowiedziami DNS (źródło: doświadczenia własne, kilka lat temu…) i trzeba będzie przeprosić się z czymś standardowym (bind, djbdns itp.). Natomiast dla kilkudziesięciu czy nawet małych kilkuset hostów powinien działać bardzo dobrze, przy minimalnym nakładzie pracy, a dając sporo opcji i możliwości (cache DNS, przygotowanie do IPv6), kosztem minimalnego tylko zużycia zasobów.

Główna zaleta dnsmasq to moim zdaniem prostota konfiguracji. Cały konfig, z definicjami zakresu, z jakiego ma przydzielać IP w DHCP, interfejsami, na których ma słuchać i określeniem wielkości cache DNS to… trzy linie. Mimo prostoty, rozwiązanie jest dość elastyczne i pozwala na parę przydatnych w sieci lokalnej tricków.

Wszystkie opcje są bardzo dobrze, z przykładami, opisane w pliku konfiguracyjnym /etc/dnsmasq.conf (Debian), do którego lektury, podobnie jak do man dnsmasq oczywiście odsyłam, poniżej przegląd kilku niezbędnych, podstawowych opcji i dodatkowo kilka najciekawszych.

Nieśmiertelna instalacja:

apt-get install dnsmasq 

Interfejs (inny, niż loopback, na którym słucha domyślnie), na którym demon ma słuchać zapytań DHCP i DNS:

interface=eth0

Oczywiście można zdefiniować więcej niż jeden, wystarczy dodać kolejne, analogiczne linie.

Zakres przyznawanych IP z DHCP, maska, czas dzierżawy:

dhcp-range=192.168.0.50,192.168.0.150,255.255.255.0,1h

Ustawienie rozmiaru cache DNS:

cache-size=150

To ustawienie (domyślne) raczej dla małej sieci, ale dzięki temu użytkownicy będą mieli kilka-kilkadziesiąt ms mniej na każdym zapytaniu DNS. I tak naprawdę te trzy linie w konfigu to wszystko, co jest potrzebne, by po prostu działało przydzielanie IP z DHCP na wskazanym interfejsie oraz cache DNS, czyli to, czego będzie potrzebować 99% korzystających. W takiej – domyślnej – konfiguracji zapytania kierowane są do serwerów DNS określonych w /etc/resolv.conf (można to zmienić).

Pora na parę troszeczkę bardziej zaawansowanych, ale przydatnych opcji (czyli nadchodzi przepisywanie manuala ;-)). Wyłączenie nasłuchu DHCP na wskazanym interfejsie (DNS nadal działa):

 no-dhcp-interface=eth1 

Oczywiście wcześniej musiałaby istnieć linia interface=eth1, żeby zadziałało.

Popularne bindowanie, czyli przypisanie IP do MAC (dany MAC zawsze otrzyma dany adres IP):

dhcp-host=11:22:33:44:55:66,192.168.0.60

Wykluczenie hosta o danym MAC z DHCP (nigdy nie otrzyma dzierżawy):

dhcp-host=11:22:33:44:55:66,ignore

Inna przydatna funkcja to umożliwienie manipulowania odpowiedziami uzyskiwanymi z serwerów DNS. Przykładowo, jeśli chcemy, by wszystkie zapytania o daną domenę były resolvowane na adres lokalny:

address=/doubleclick.net/127.0.0.1

Oczywiście linii może być więcej, czyli de facto można zrobić mały, lokalny DNS blackholing. Odpowiadać można zarówno adresami IPv4, jak i IPv6. Powyżej rozwiązanie dla reklam, ale równie dobrze można tym sposobem popsuć trochę szyki malware’owi, albo dać znać użyszkodnikom, że admin czuwa i NK w trakcie pracy to niekoniecznie dobry pomysł…

W przypadku IPv4 można też „naprawiać” odpowiedzi otrzymywane z nadrzędnych serwerów DNS:

alias=1.2.3.4,5.6.7.8

Dzięki powyższemu odpowiedź 1.2.3.4 zostanie przetłumaczona na 5.6.7.8.

Działa także dla całych zakresów:

alias=1.2.3.0,5.6.7.0,255.255.255.0

Powyższe powoduje, że każdy adres 1.2.3.x jest mapowany do 5.6.7.x

Teraz bonus dla wytrwałych czytelników, czyli opcja zwiększająca bezpieczeństwo, której nie ma w przykładowym konfigu (jest w manie, daje się dodać do konfiga).

stop-dns-rebind 

Chodzi o blokadę (i logowanie) odpowiedzi z nadrzędnych DNSów, które są adresami prywatnymi (stosowane do ataków na sieci lokalne, np. do zmiany konfiguracji routerów). Warto jednak doczytać o pozostałych opcjach typu rebind w manualu, żeby np. nie zepsuć DNS blackholingu na upstreamowych DNS…

Podstawowe opcje związane z TFTP

enable-tftp

powoduje włączenie TFTP. Można podać interfejs, na którym ma słuchać TFTP

enable-tftp=eth0

Można też ustawić różne katalogi TFTP obsługiwane na różnych interfejsach. W tym celu należy użyć

tftp-root=/katalog,eth0
tftp-root=/katalog2,eth1

Ostatnia przydatna opcja to

log-queries

które spowoduje logowanie zapytań DNS do pliku. Przydatne np. przy debugu, statystyce odpytywanych domen i przy permanentnej inwigilacji.

I tak naprawdę to koniec popularniejszych opcji (choć opcji jest dużo więcej). Moim zdaniem tyle wystarczy, by zachęcić do przyjrzenia się temu rozwiązaniu na mniejszych sprzętach i/lub sieciach. W wielu przypadkach nie ma sensu stosowania „dużych” rozwiązań typu dhcpd od ISC czy „pełny” serwer cache’ujący DNS.

Z innych, bardziej systemowych zastosowań dnsmasq – może być przydatny dla środowisk chroot z nieskonfigurowanym /etc/resolv.conf. Jeśli w /etc/resolv.conf nie ma żadnego działającego nameserwera, to odpytywany jest loopback. Dnsmasq domyślnie słucha na loopbacku, więc zapewni działające DNSy systemom w chrootach. Źródło: Simple DNS in chroots.

Jeszcze inną – ciekawą z punktu widzenia sysadminów – właściwością dnsmasq jest fakt, że domyślnie zapytania DNS kierowane są jednocześnie do wszystkich serwerów DNS. Bez żadnego, najmniejszego opóźnienia (czego AFAIK nie da się uzyskać przy korzystaniu wyłącznie z /etc/resolv.conf). Dla tych zastosowań, dla których działanie DNS jest krytyczne i nawet 1 sekunda w odpytaniach jest niedopuszczalna, dnsmasq być sposobem na zrównoleglenie odpytań serwerów DNS.

Na koniec odpowiedź na pytanie, jak sprawdzić, czy dnsmasq w ogóle działa. Należy wydać polecenie kill -USR1 `pidof dnsmasq`, następnie można sprawdzić w syslogu, co się pojawiło – grep dnsmasq /var/log/syslog. Powinny tam się znaleźć linie w stylu (nie ma hitów, bo niski uptime):

wielkość pamięci podręcznej: 2000; 0 z 212 miejsc aktualnych wpisów użyto ponownie.
171 zapytań przesłanych dalej, 467 odpowiedzi udzielonych samodzielnie

UPDATE: Dodane info i przykłady dla TFTP.

UPDATE: Dodany przykład jak uzyskać statystyki wykorzystania pamięci cache.

Licencja wpisu: CC BY-NC-SA (wyjątkowo, specjalnie dla jakilinux.org z okazji dyskusji nt. wpisu o DHCP od ISC). W związku ze zmianą licencji globalnie, w dodatku na bardziej liberalną, zapis ten nie ma już sensu.

Naprawienie hibernacji w Squeeze.

W poprzednich narzekaniach na Debiana pisałem, jak to mi hibernacja szwankuje, mimo zgłoszonych bugów. Nie ma co ukrywać, powrót tematu hibernacji w tej dyskusji i chęć zepsucia czegoś doprowadziły do tego, że stwierdziłem, że trzeba poszukać problemu. Metodą najdoskonalszą, czyli izolacji problemu.

Podejrzanych było dwóch: hibernate i uswsusp. Na początek stwierdziłem, że wyrzucę oba pakiety wraz z konfiguracjami (wajig purge…) i zobaczę, jak LXDE reaguje. Ku memu zdziwieniu, opcje hibernacji i usypiania nadal były dostępne. Kliknąłem jedną z nich i… ku memu zdziwieniu zadziałała. Znaczy się, winnych może być więcej. Szybki reboot i dalsze działanie uśpienia upewniły mnie, że musi być inny winny.

Wizyta na kanale #debian (hibernacja to dla mnie nowość, przyznaję się od razu, że ten temat jest mi praktycznie obcy, jakoś nigdy nie widziałem sensu tego) przyniosła newsa: jest jeszcze pakiet pm-utils, który może zapewniać dostęp do usypiania i hibernacji. Został odinstalowany i zainstalowałem od nowa uswsusp. Tradycyjnie nie banglał. Wywaliłem go i stwierdziłem, że dam szansę narzędziom z pm-utils. Ku memu zdziwieniu opcje testowe pokazywały, że powinno działać z ich użyciem i uśpienie, i hibernacja. I faktycznie działają one pod Squeeze od kopa i elegancko.

Pomysłu co może być przyczyną niedziałania uswsusp na kanale nie ma, maintainer pakietu jakoś się nie odzywa w zgłoszeniu błędu. Szkoda, bo uswsusp miał trochę ciekawych opcji (kompresować czy nie, szyfrować czy nie)… Za to dostałem namiar na stronę dotyczącą MIA Team. 😉

Znowu wszystko działa i Debian robi się nudny

Odzyskiwanie miejsca w systemie (Linux, Windows).

Używany system ma tendencję do powolnego gubienia miejsca. Niezależnie od tego czy mamy w systemie porządek, czy nie, z czasem przybywa rzeczy, których nie potrzebujemy. Z jednej strony są to bardzo potrzebne pliki, których po prostu szkoda skasować (chociaż tak naprawdę nigdy już ich nie otworzymy), z drugiej nieużywane pakiety, konfiguracje usuniętych pakietów, pliki tymczasowe itp.

O ile z pierwszymi nie bardzo można sobie poradzić inaczej, niż samodzielnie utrzymując porządek (sortowanie do katalogów, kasowanie zbędnych rzeczy) i ręcznie usuwając pliki, to w przypadku tych drugich można sobie pomóc w czyszczeniu systemu różnymi automatami i półautomatami.

Pierwszy złodziej miejsca w systemie to cache apt-a, czyli /var/cache/apt/archives. Leżą tu paczki deb instalowanych pakietów. We wszystkich wersjach, także tych starszych. Praktycznie nigdy nie będą potrzebne, więc z czystym sumieniem możemy je skasować: wajig clean (lub, bardziej kanonicznie apt-get clean).

Drugi popularny złodziej miejsca to locale, czyli różne wersje językowe dla danego programu. Zwykle nie potrzebujemy dokumentacji itp. po hiszpańsku, włosku czy chińsku. Rozwiązanie: localepurge (po uprzednim skonfigurowaniu, fajnie jakby coś jednak zostało…).

Potem można zobaczyć, czy nie zostały w systemie pliki konfiguracyjne po usuniętych pakietach. Przy okazji sprawdzimy, które pakiety zajmują najwięcej miejsca: wajig sizes. Status inny niż installed oznacza, że raczej możemy się pozbyć pakietu w całości, czyli z konfigami (wajig purge <pakiet>).

Na koniec jeszcze deborphan (albo wersja ładniejsza w curses czyli orphaner) i usuwamy zainstalowane na potrzeby spełnienia zależności niepotrzebne pakiety (głównie biblioteki).

Tu się zwykle sprzątanie kończy. No dobrze, można jeszcze skorzystać z jednego z przydatnych poleceń i spojrzeć, które katalogi zajmują najwięcej miejsca (du –max-depth=1 -b | sort -n) i ręcznie pousuwać zbędne rzeczy (typu cache googleearth).

Dłużej używane systemy mają tendencję do gromadzenia pakietów z poprzednich wersji (szczególnie, jeśli korzysta się z wersji niestabilnej lub miesza kilka wersji systemu). Można je łatwo wytropić (i usunąć) korzystając z opisanego sposobu: wajig versions | grep -v squeeze.

A dziś odkryłem wisienkę na czubek tortu: BleachBit. Narzędzie jest wieloplatformowe (Linux, Windows) z funkcjami typowo Debianowymi (bardziej Ubuntu pewnie) i zajmuje się takimi cichymi złodziejami miejsca jak cache różnych aplikacji. Poza tym, że sięga tam, gdzie inne automaty nie sięgają, umie też czyścić rzeczy typowo systemowe: wspomniany cache apta, nieużywane lokalizacje (twórcy BleachBit twierdzą, że robi to znacznie skuteczniej, niż localepurge, faktycznie znalazł więcej).

Posiada zarówno miłą klikalną wersję GUI (z której korzystałem) jak i interfejs CLI (nie próbowałem). Do tego dobre podpowiedzi do opcji (ostrzega przed opcjami powolnymi i potencjalnie niebezpiecznymi). Działa bardzo fajnie, więc zdecydowanie polecam, jeśli ktoś planuje porządki w systemie (a chyba każdy prędzej czy później staje przed pytaniem jak odzyskać miejsce w systemie?). Użycie jest proste: najpierw wybiera się, co chce się usunąć, potem jest podgląd plików do usunięcia (warto spojrzeć co będzie usuwane – wywala np. pliki bak i inne tymczasowe – czasami może tam być coś pożytecznego…). Program dba o prywatność użytkownika – jako opcja dostępne jest nadpisywanie zawartości kasowanych plików przed ich usunięciem.

Jedyne do czego można się przyczepić, to spolszczenie. Zapewne w oryginale był vacuum (bazy danych), a został… odkurzacz. I parę innych kwiatków tego typu, ale IMHO nie rzutuje na całość.