Własna namiastka dyndns

Po ostatniej akcji Microsoftu z przejęciem i zablokowaniem domen należących do No-IP miałem przez moment umiarkowany problem z dostępem do jednej z moich maszyn, bo nie znałem IP. Nic krytycznego i szybko rozwiązałem, ale stwierdziłem, że warto by się zabezpieczyć na przyszłość. Początkowo chciałem uruchomić po prostu innego dostawcę dyndns, z inną domeną, co dałoby całkiem niezłą – jak mi się wydaje – redundancję w tym względzie, ale prowizorycznie uruchomiłem coś innego, własnego i znacznie prostszego. W komentarzu do poprzedniego wpisu padło pytanie co dokładnie zrobiłem, więc opisuję.

Tak się składa, że mam serwer dedykowany ze stałym IP (nie jest konieczne zamiast tego można skorzystać z domeny), na którym stoi serwer WWW (lighttpd). Na wszystkich maszynkach potrzebujących dyndns mam dostęp do crona (zresztą, korzystałem z crona już przy zwykłym koncie dyndns, patrz update wpisu). Rozwiązanie jest proste: klient wywołuje okresowo unikatowy URL na moim serwerze, serwer okresowo parsuje log w poszukiwaniu tego unikatowego ciągu znaków i zapisuje IP z którego nastąpiło odwołanie w określonym pliku.

Poniżej wklejki ze wszystkimi onelinerami (gotowiec dla lighttpd, w przypadku innego serwera WWW trzeba dostosować):

# po stronie klienta*/5 * * * * /usr/bin/wget -4 -q -O /dev/null http://mojadomena.com/losowyciagznakow4346456543324645 > /dev/null
 # po stronie serwera*/5 * * * * /usr/bin/awk '/losowyciagznakow4346456543324645/ {ip=$1} END {print ip}' /var/log/lighttpd/access.log > /var/www/dyndns_host1.txt
 # pobranie IPwget -O - http://mojadomena.com/dyndns_host1.txt

Po namyśle, rozwiązanie nawet lepsze niż drugi dostawca dyndns. Mniej kont, prostsza konfiguracja, mając stałe IP na upartego można całkowicie uniezależnić się od DNSów, jeśli ktoś odczuwa potrzebę.

Oczywiście nie od razu tak to wyglądało, w szczególności po stronie serwera był grep, awk, tail w użyciu. Ale skoro da się wszystko załatwić awk (a nie tylko wyświetlanie określonej kolumny, chyba najczęstsze zastosowanie awk…), to czemu nie? Tu polecam zbiór przydatnych onelinerów w awk.

UPDATE: IPv6 się popularyzuje. Okazało się, że mój skrypt nie działa poprawnie, bo łączenie między maszynami następuje po IPv6. Dodany parametr -4 do wget w celu naprawy tego problemu.

Dyn.com kończy świadczenie darmowych usług

Dla mnie konto na dyn.com skończyło się wcześniej, dziś ogłosili na blogu, dlaczego zdecydowali się zaprzestać świadczenia darmowych usług w ogóle. Przyznam, że byłem zadowolony w tym wąskim zakresie, w jakim korzystałem, ale dopiero sposobem wyłączenia i rozłożeniem go w czasie mnie ujęli. PRowo jak dla mnie wzorowo: mocno rozłożone w czasie, narastający poziom trudności w utrzymaniu darmowych usług, możliwość łatwego przejścia na wariant płatny, dobra informacja (OK, to w ich interesie). Last but not least: utrzymanie obiecanych wiecznych darmowych kont wczesnym użytkownikom. Naprawdę uważam za ładnie rozegrane.

Pozostało mi życzyć im powodzenia i podziękować, zatem: thank you, dyn.com. 🙂

Własny DNS cache jako lekarstwo na problemy z siecią

Jest powiedzenie, że nowe to dobrze zapomniane stare. Tak jest w przypadku DNS i ataków różnej maści. Niedawno głośno było o DDoSach z użyciem DNS amplification, potem o podmianie DNS (głównie na routerach, nie jak kiedyś na komputerach, ale cel ten sam), a od niedawna popularne stało się generowanie dużej ilości zapytań do serwerów DNS rekursywnych ISP (AFAIK też ostatecznie rodzaj DDoSu). Na tyle dużej, że niektórzy operatorzy mieli/mają problemy z obsłużeniem żądań pochodzących od swoich klientów na swoich serwerach cache’ujących.

Z różnych pokątnych źródeł (Facebook, IRC) wiem, że pierwszego dnia, gdy się to zaczęło, były problemy z dostępem do Internetu w sieciach należących do Inei i Multimedii. Nie znam przyczyny, ale biorąc pod uwagę, że jeszcze jednemu providerowi „kończyły się” maszyny obsługujące rekursywne DNS i że w przypadku Multimedii pomagała zmiana w systemie na np. serwery DNS Google, przypuszczam, że chodzi właśnie o niewydolność serwerów DNS dostarczanych użytkownikom tych sieci przez ISP.

Rozwiązanie jest dość proste – wystarczy uruchomić swój serwer DNS rekursywny lub forwarder na desktopie czy routerze w swojej sieci, by sieć zaczęła działać lepiej i być mniej zależna (lub nawet niezależna) od DNSów naszego ISP. Ja na swoich desktopach (oczywiście Linux) od dłuższego czasu mam uruchomionego unbound (pokłosie benchmarków DNS) – jest lekki i bezproblemowy. W obecnej sytuacji mamy podwójną korzyść z własnego cache: po pierwsze, jak zwykle odpowiedzi udzielane będą nieco szybciej[1], po drugie, uniezależniamy się od serwerów naszego ISP, który w związku z niewesołą sytuacją w sieci może mieć problemy z działaniem w ogóle.

Z kolei w przypadku sieci lokalnych i routerów sprzętowych działających pod kontrolą OpenWrt lub podobnego systemu warto zwrócić uwagę na mały i zgrabny dnsmasq, którego konfigurację opisywałem kiedyś dość dokładnie.

Niezależnie od wyboru, koniecznie pamiętajmy o zabezpieczeniu czyli poprawnej konfiguracji naszego serwera DNS. Obsługujmy zapytania rekursywne tylko z naszej zaufanej sieci (np. LAN). W przeciwnym razie nasz serwer może zostać wykorzystany do DDoS poprzez DNS amplification. Ograniczać można na wiele sposobów w zależności od użytego serwera i możliwości: firewall, ograniczenie nasłuchiwania do konkretnego interfejsu lub definicje obsługiwanych prefiksów w konfiguracji samego serwera.

[1] Nie zawsze jest to prawdą, liczy się nie tylko opóźnienie do serwera, ale także zawartość jego cache czy wydajność sprzętu, na którym działa. Pisałem kiedyś szerzej o wyborze serwera DNS.