Homelab #10: organizacja routingu oraz https

W tej części chciałbym opisać ostatnie zmiany, jakie zrobiłem w homelab. W szczególności chciałbym opisać, jak organizowałem routing w sieci.

Dotychczasowe rozwiązanie

Do tej pory miałem jako-tako rozwiązany dostęp do serwisów hostowanych lokalnie. Był to jednak bardziej zorganizowany chaos niż dobrze zaplanowany system. Z zasady nie miałem https – szczerze mówiąc, nie do końca widzę sens TLS w domowej sieci. Po pierwsze, to i tak użytki domowe, a po drugie – jeśli ktoś już ma dostęp do lokalnego PiHole, to mam większe problemy niż brak szyfrowania…
Tak więc wszystko było na http. Od początku postanowiłem, że wszystkie maszyny oraz LXC będą miały host jako jedno słowo: dns, media, nas, homelab, itd. A wszystkie serwisy będą w .home, np. pihole.home, docs.home, itd.
Przez bardzo długi czas to rozwiązanie działało dobrze. Owszem, niektóre serwisy pokazywały komunikaty o konieczności używania https, ale nie było to szczególnie uciążliwe.

Teraz bardziej techniczne szczegóły. Przez ostatnie kilka lat używam Traefik jako reverse proxy, gdy potrzebuję obsłużyć więcej niż kilka serwisów. W związku z tym od początku, niemal jako pierwszy serwis, w homelab wdrożyłem Traefik. Dodatkowo DNS konfigurowałem w PiHole, bo to mój główny DNS resolver w sieci. A żeby organizować dostęp do wszystkich lokalnych serwisów, korzystałem z JAD.

Problem

Pewnego dnia postanowiłem spróbować Vaultwarden (backend do Bitwarden) i tutaj pojawił się problem: Bitwarden można używać tylko mając TLS…

I chociaż teoretycznie wiedziałem, co jest do tego potrzebne:

• reverse-proxy,
• DNS,

to jedyną rzeczą, której mi brakowało (i o której nie chciałem na początku myśleć), była domena.
Bardzo, ale to bardzo nie chciałem mieć w sieci domowej routingu z normalnym domain name. Chciałem coś bardzo customowego, co od razu dawałoby do zrozumienia, że nie jest to hostowane na zewnątrz. Nie wiem czemu, ale bardziej pasuje mi pihole.home lub pihole.local niż pihole.homelab.domena.com.

Niestety, to jedyne sensowne rozwiązanie, żeby dostać normalny certyfikat SSL.

Oczywiście można wygenerować SSL dla dowolnej lokalnej domeny za pomocą własnego CA. Ale takie rozwiązanie sprawdza się tylko, jeśli w sieci jest kilka urządzeń, bo aby działało poprawnie, CA musi być zainstalowany na każdej maszynie. A np. instalacja customowego CA na telewizorze LG jest teoretycznie możliwa, ale na pewno nie chcę się w to bawić. Jedyną opcją, jaka mi pozostała, była migracja na zwykłą domenę.

SSL

Spędziłem trochę czasu na poszukiwaniu dostępnej domeny, która z jednej strony pasowałaby do tematu lokalnej sieci, a z drugiej była krótka i sensowna… Niestety, znaleźć coś takiego obecnie graniczy z cudem. Najtańszą i najprostszą opcją było użycie domeny, którą już miałem: serhiy.io. Tak więc dodałem do niej subdomenę home: home.serhiy.io i postanowiłem tworzyć domeny lokalnych serwisów w tym schemacie.

Mając już Traefik, jedyne co musiałem zrobić, to dodać dane logowania do Cloudflare i uporządkować hosty wszystkich serwisów. O tym, jak w prosty sposób uzyskać SSL, pisałem tutaj.

DNS

Nie chodzi o to, żeby mieć dostęp do serwisu przez internet przy użyciu domeny – domena jest konieczna tylko po to, żeby wygenerować certyfikat SSL. W skrócie:

• generujemy SSL dla domeny service.test.com,
• instalujemy certyfikat w reverse proxy,
• konfigurujemy serwis w reverse proxy pod wybraną domenę.

Ale jakim cudem service miałby być dostępny pod adresem service.test.com? Tutaj wchodzi lokalny DNS. Główny trick polega na dodaniu wpisu A w lokalnym DNS, który wskazuje na IP reverse proxy jako serwer dla domeny service.test.com.

• dodajemy w DNS rekord A.

W ten sposób serwis jest dostępny pod adresem service.test.com, ale tylko w sieci lokalnej, bo serwer DNS przekierowuje wszystkie zapytania https z service.test.com na lokalny reverse proxy, a stamtąd na serwis już po http.

Organizacja nazewnictwa

Mając wybraną domenę i SSL, kolejnym krokiem było uporządkowanie domen. Do tej pory używałem pihole.home, teraz wszystko zmigrowałem na home.serhiy.io. W efekcie nowa domena PiHole to pihole.home.serhiy.io (choć faktycznie używam dns.home.serhiy.io, bo jest wygodniejsze i bardziej logiczne).

Przykładowe serwisy:

• pve.home.serhiy.io
• ui.home.serhiy.io
• nas.home.serhiy.io
• dns.home.serhiy.io
• jellyfin.home.serhiy.io
• docs.home.serhiy.io

Jak widać, każdy serwis w sieci lokalnej dostał nową domenę w *.home.serhiy.io.

Bonus: konfiguracja w PiHole

Najbardziej denerwujące w dodawaniu nowego serwisu do homelab było to, że musiałem otwierać PiHole i ręcznie wpisywać domenę oraz IP reverse proxy…
Pomyślałem: może PiHole ma opcję dodania wildcard *, tak żeby wszystkie domeny w *.home.serhiy.io wskazywały na reverse proxy? Niestety, domyślnie PiHole tego nie obsługuje. Za to obsługuje to dnsmasq, którego PiHole używa do zarządzania DNS. Wystarczy więc skonfigurować plik dnsmasq by to działało. Dodajemy linię:
address=/home.serhiy.io/192.168.2.33
do pliku /pihole/etc-dnsmasq.d/01-pihole.conf, restartujemy PiHole i powinno działać. U mnie jednak z jakiegoś powodu to nie zadziałało :(
Po chwili googlowania okazało się, że jest prostsze rozwiązanie. W samym PiHole można dodać własną linię konfiguracyjną do dnsmasq:

Opcja jest dostępna w: Settings -> All settings -> Miscellaneous.

Podsumowanie

To było kolejne popołudnie spędzone na ulepszaniu sieci domowej. Teraz bez problemu mogę korzystać z Bitwarden, a wszystkie alerty dotyczące konieczności używania SSL w aplikacjach hostowanych lokalnie zniknęły. Automatyzacja w Traefik razem z Cloudflare całkowicie rozwiązuje problem odnowienia certyfikatów SSL, więc mam nadzieję, że w najbliższym czasie nie będę musiał nic zmieniać w tym temacie.