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.

Dziwny problem z Javą i siecią w Debianie.

Z programów napisanych w Javie korzystam raczej rzadko (wyjątkiem jest bloxer2, którym od dłuższego czasu wrzucam tu wpisy), więc nie zauważyłem tego wcześniej. Debian w wersji Squeeze, Java z repozytorium (wersja 6.20-dlj-1).

Jedna ze stron nie mogła załadować appletu i rzucała:

load: class VncViewer.class not found
[różności] 
Caused by: java.net.ConnectException: Network is unreachable

Ta sama aplikacja nie działała wcześniej na samodzielnie robionej Javie od Sun, z kolei działała (i nadal działa) na różnych wersjach Javy w Debianie Lenny. Na szczęście coś mi świtało, że ogólnie jest problem z IPv6 w Javie, szybkie gógiel potwierdził, więc pozostało znalezienie, co trzeba zmienić. Dobrzy ludzie z IRCa pomogli (!java ipv6), więc przybliżę rozwiązanie.

Winne jest zmienione domyślne ustawienie dla IPv6 w Debianie Squeeze. Okazuje się, że błąd jest zgłoszony, a działanie sieci pod Javą przywraca (tzn. w części aplikacji, niektóre działają bez problemu) ustawienie w pliku /etc/sysctl.d/bindv6only.conf:

net.ipv6.bindv6only = 0

Netcamp po raz pierwszy.

Nieco o Netcampie słyszałem, ale nigdy nie miałem okazji się wybrać. Albo mnie nie ciągnęło, albo nie miałem czasu. Wczoraj pierwszy raz nawiedziłem imprezę, głównie za sprawą prezentacji (współ)prowadzonej przez Malina. Krótkie wrażenia poniżej.

Organizacja Netcampu

Tematy były trzy, z czego okazało się, że w sumie tematycznie prezentacja na którą przyszedłem (FilesTube) jest najbardziej odległa od moich zainteresowań. Założenia prowadzenia prezentacji (szczytne) są spisane na stronie. Pierwszy mały zgrzyt – na miejscu, kilkanaście minut przed startem, prelegenci dowiedzieli się, że „ze względu na oszczędność czasu na podłączanie sprzętu” nie będą mogli prowadzić na swoim sprzęcie. Co prawda stanęło na tym, że i tak każdy prowadził na swoim sprzęcie (nawet na jednym Linuksie było – dało się uruchomić rzutnik ;-)), ale niesmak pozostał – o takich rzeczach uprzedza się grubo wcześniej, albo nie wygłupia się z takimi ograniczeniami – skoro ktoś chce „przymierzyć” wcześniej, czy wszystko działa, ew. skonfigurować, a potem tylko podłączyć (get real, i tak były przerwy po 10-15 minut między prezentacjami), to nie widzę sensu utrudniania.

Kolejne dwa minusy to: brak miejsca na kurtki/płaszcze (może coś było, ale słabo eksponowane, bo wielu ludzi siedziało z kurtkami) oraz słaba wentylacja. O ile kiepską wentylację jestem w stanie przyjąć do wiadomości (chociaż można przynajmniej w przerwie wietrzyć – w czasie prezentacji hałas z ulicy może przeszkadzać), to szatnię warto wyeksponować (jeśli jest) lub zrobić jakąś (zwykłe wieszaki w liczbie kilku starczą). No i jak widać, że minimum połowa ludzi kisi się z kurtkami, to można – chociażby zapowiadając przerwę – powiedzieć o szatni (jeśli jest). Tyle krytyki strony organizacyjnej – poza tym było OK, bez zgrzytów ze sprzętem i prowadzeniem.

Prezentacja pierwsza

Prezentacja pierwsza – klaster obliczeniowy na bazie komputerów poleasingowych. Trochę się kiedyś interesowałem tematyką sprzedaży mocy obliczeniowej i… to nie działa. Projekt cpushare.com (dead link) jest może nie tyle martwy, co nierozwijany, a była szansa na to, że każdy może handlować (w obie strony) mocą obliczeniową. Tymczasem założenia w prezentacji to – firmy pozbywają się sprawnego sprzętu (rzędu PIV 1GB RAM) po okresie leasingowym (płacąc firmie zajmującej się utylizacją), istnieją chętni na kupno dużych ilości mocy obliczeniowej, superkomputery są drogie (Galera ok. 7 mln zł), a koszty eksploatacji klastra (do Galery przyrównano klaster z 6 tys. komputerów) są pomijalne (nie tyle pomijalne, co niskie). Więc firmy oddadzą sprzęt za free OPP (tak, organizacja pożytku publicznego), która zajmie się budową klastra i będzie odsprzedawać moc obliczeniową.

Prawie wszystko fajnie, ale IMO to się nie spina finansowo (czego dowodzi upadek cpushare.com, działającego przecież w bardziej elastycznych warunkach). Licząc skromne 50W (IMO mało, bo tyle to sam procesor może wziąć, a płyta, a sprawność zasilacza… no ale OK) na pojedynczy węzeł w klastrze, dla 6000 sztuk mamy pobór mocy rzędu 300 kW. Prowadzący wspominał coś o UPSach, redundancji zasilania (dwie linie dosyłowe) oraz generatorach Diesla, ale dla 50W już sam prąd to minimum 15 zł miesięcznie na węzeł (dla wyszukanych danych sprzed 3 lat, IMO obecnie bardziej na miejscu byłaby cena 0,6zł/kWh zamiast 0,42 zł/kWh; wg taryfy dla domu, tu pewnie wejdzie inna taryfa, jeśli ktoś jest na bieżąco, to proszę skorygować), czyli ok. 1 mln zł rocznie (a jeszcze ciepło trzeba odprowadzić). Może przy współpracy z elektrociepłownią i odzyskiwaniem energii do ogrzewania się to zepnie. Może.

Jeśli jednak pobór prądu ma być krytyczny, to Nautilus ze swoimi 18 TFlops i poborem 35 kW wypada 3 razy lepiej (ok. 100kW/50TFlops) niż składak z prezentacji, dając oszczędności ok. 0,7 mln zł rocznie w porównaniu ze składakiem… Podsumowując: jak dla mnie stawianie czegoś takiego w Polsce mija się z celem. No i sama teza, że „będą chętni do kupienia mocy obliczeniowej” też wydaje się naciągana – w końcu jest cała armia ludzi, którzy chętnie moc sprzedadzą (obecnie nawet oddają za darmo – patrz BOINC – jakieś 4312 TFlops).

Prezentacja druga

Prezentacja druga – Optymalizacja serwisów internetowych na przykładzie FilesTube – czyli to, na co przyszedłem. Prezentacja ciekawa (bardzo kojarzyła mi się z niegdysiejszymi prezentacjami Allegro i Naszej Klasy na którymś PLNOG i spokojnie mogłaby obok nich się pokazać) tylko… nie związana z tematem, moim zdaniem. Dowiedziałem się sporo o serwisie, o historii rozwoju, sporo o rozwiązaniach (architektura, soft, hardware, wykorzystane technologie) stosowanych w przeszłości, obecnie oraz planach, o modelu biznesowym. Padła teza, kiedy (nie) optymalizować, ale IMO zabrakło przekonujących przykładów, czemu właśnie wtedy (jeśli dobrze zrozumiałem to dewizą jest robimy jak bądź, jak się przestaje wyrabiać, to patrzymy czemu i optymalizujemy ten fragment). OK, to – jak widać – działa, ale czy faktycznie jest najlepszym podejściem? Czy próbowano innego? Powiedzenie nasza droga jest dobra będzie zawsze prawdziwe w przypadku firmy/produktu, który odniósł sukces, ale nie znaczy to, że nie ma innych (w tym: lepszych) dróg (zwłaszcza, że – jak słyszałem na prezentacji – aktualnie mają pewien problem z peakami ruchu).

Tu kolejna rzecz, sukces i chwalenie się nim. Bardzo mi tego zabrakło, a 2 razy więcej UU, niż ma Nasza Klasa (24 mln vs. 12 mln, dane z prezentacji) to IMO powód do reklamy i serwisu, i firmy, i miasta. O firmie i serwisie było do niedawna cicho, trochę za dużo na prezentacji dostrzegłem podejścia „robimy to tak i tak, no i jakoś się udało”. Jasne, szczęście też trzeba mieć, sam dobry produkt nie gwarantuje (IMO zwł. w necie) sukcesu, ale – skoro przy zerowych nakładach na marketing – serwis odniósł ogromny sukces (nazywajmy rzeczy po imieniu) to brak chwalenia się mnie po prostu dziwi. Może zaważyła tematyka (podobało mi się „piractwo, jakie piractwo?”), ale jak sami twórcy mówią, współpracują z organizacjami zajmującymi się ochroną praw autorskich…

Gdybym nie miał porównania z Allegro i Naszą Klasą, to cała prezentacja byłaby dla mnie skali „a tu mam taki serwis i on się zmieniał tak a tak” – nie czułem skali zjawiska, powiedzenie, że coś się wykonywało kilkanaście godzin, a po optymalizacji kilka minut też nie oddaje tego, czy było tak fatalnie na początku napisane, czy było napisane wg standardowego podejścia i po prostu skala jest taka, że przestaje się ono sprawdzać.

Prezentacja trzecia

Prezentacja trzecia – czyli dlaczego IPv6. Najbardziej tematycznie mi pasująca i… zdecydowanie najsłabsza. O ile mi udawało się nadążyć za tokiem myślenia i skrótami myślowymi prowadzącego, o tyle jestem przekonany, że niesieciowcy zrozumieli niewiele. Było o wszystkim – co to IPv6, czemu nie IPv4, historia i rozwiązania historyczne, wszystko mocno chaotyczne plus skróty myślowe ocierające się o błąd rzeczowy (np. „przydzielanie adresów IP za pomocą RADIUSa”). Brak czytelnego przesłania, skakanie po łebkach, mnóstwo pojawiających się i znikających nazw, brak jasnych przykładów – słabo. Plus za chęci, plus za humor, ale… to się nie broni. Nie dla laików, nie w tak krótkim czasie. Na PLNOGu wykłady były dłuższe, głębsze, dla sieciowców i tamto miało sens, więcej było też o możliwych problemach.

Po tym wykładzie przeciętny słuchacz IMO albo doczyta (oraz znajdzie aktualne rozwiązania wśród historycznych), spróbuje u siebie włączyć i się zniechęci problemami, albo zada sobie pytanie „co mi da działanie mojego serwisu/strony/system po IPv6” i… niestety nie będzie umiał na nie odpowiedzieć. IMO przy tak skróconym czasie warto było odpuścić historię (która dodatkowo miesza słuchaczom w głowach) i skupić się na rozwiązaniach bieżących.

Podsumowanie

Cieszę się, że byłem. Co prawda spotkałem się z opinią, że ten Netcamp był wyjątkowo ciekawy, ale mi się podobało (a porównania nie mam) i cieszę się, że taka impreza jest organizowana. Zapewne przyjdę kolejny raz, jeśli będę miał okazję i nie tylko po to, by się ze znajomymi spotkać (a taka była oryginalnie moja motywacja).