Prywatna chmura za 50€ (Hetzner, Proxmox, pfSense, HAProxy, Docker Swarm, Portainer, Suricata, PBS)

Stwórz bezpieczne, wydajne i niedrogie środowisko dla swoich aplikacji kontenerowych na serwerach dedykowanych Hetznera.
Za około 50€ miesięcznie.

Tę konfigurację można zrealizować także u innych dostawców serwerów, zarówno dedykowanych, jak i współdzielonych, a nawet w chmurze publicznej. Ten poradnik nie był sponsorowany przez Hetznera ani żadnego innego producenta oprogramowania. Jeśli interesuje Cię podobna konfiguracja, napisz do mnie na LinkedInie.

Cel #

Celem tej konfiguracji jest uruchamianie kontenerów Docker w trybie Swarm w bezpiecznym i niezawodnym środowisku. Ze względów bezpieczeństwa włączamy firewall Proxmoxa, firewall pfSense oraz IDS/IPS Suricata. Ze względu na niezawodność konfigurujemy md RAID i tworzymy 3 różne, uzupełniające się miejsca docelowe backupów. Aby zamienić tę konfigurację w produkcyjną, wystarczy dodać dwa lub więcej węzłów Proxmoxa i dwa lub więcej węzłów Swarm. I możesz już prowadzić swój biznes online.

Serwery dedykowane Hetznera #

00:10: Zaczynamy od wizyty w portalu Hetznera o nazwie Robot. Służy on do zarządzania serwerami dedykowanymi. Możemy albo wynająć zupełnie nowy serwer z najnowszym dostępnym sprzętem, albo udać się na aukcję serwerów, gdzie sprzęt jest nieco starszy, ale w lepszych cenach. Na potrzeby tego testu wybiorę serwer z aukcji z co najmniej 3 dyskami i 64 GB pamięci. Zarówno w konfiguracjach testowych, jak i produkcyjnych sugeruję wybór procesorów klasy enterprise, takich jak Xeony, które w dłuższej perspektywie sprawują się lepiej i są znacznie stabilniejsze niż procesory desktopowe.

Po złożeniu zamówienia trzeba poczekać na jego realizację, co w większości przypadków powinno zająć od 15 do 30 minut, ale w przypadku niestandardowej konfiguracji trzeba czekać nawet 5 dni roboczych, więc zamawiaj z odpowiednim wyprzedzeniem. Zamówienia będą widoczne w sekcji Server, gdzie możesz obejrzeć serwer, wysłać zdalny restart lub zamówić konsolę szeregową w razie problemów. Następnie nadajesz serwerowi nazwę i dodajesz go do wirtualnego przełącznika o nazwie vSwitch. Umożliwi to serwerowi komunikację z innymi Twoimi serwerami przypisanymi do tego samego vSwitch ID. Ważne: MTU musi wynosić 1400. Na potrzeby naszej konfiguracji testowej zamawiam też dodatkowy publiczny adres IP. Trzeba napisać uzasadnienie jego użycia, ponieważ pula IP4 jest ograniczona. Ten dodatkowy publiczny adres IP będzie używany przez router/firewall pfSense, który obsłuży cały ruch operacyjny.

Wirtualizacja Proxmox #

01:52: Po zrealizowaniu zamówienia otrzymujesz e-mailem hasło użytkownika root, więc zmień je przy najbliższej okazji. Łączę się z serwerem przez SSH, gdzie widać krótki przegląd tego, co jest w środku: jaki mamy procesor i dyski oraz jaki typ karty ethernet jest zainstalowany. Instalację systemu można uruchomić za pomocą narzędzia installimage. Kilka rzeczy jest tu ważnych: SWRAID, SWRAIDLEVEL, HOSTNAME i konfiguracja partycji. Instaluj tylko na 2 dyskach tego samego rozmiaru, a pozostałe zostaw nieskonfigurowane. Programowym mirrorem, podobnym do RAID, zajmie się md. Nie instaluj systemu na dyskach talerzowych, ponieważ będzie to znaczące wąskie gardło pod względem dostępnego IO, które będzie odczuwalne.

Po zakończeniu instalacji Debiana zrestartuj serwer i poczekaj, aż znów będzie dostępny. Jeśli serwer nie wraca, zrestartuj go z panelu Robot. Połącz się ponownie przez SSH i rozpocznij instalację Proxmoxa według mojego poradnika krok po kroku. Obejmuje on aktualizację systemu, dodanie wymaganych repozytoriów oraz instalację pakietów i usług Proxmoxa. Szybkość tego procesu zależy od specyfikacji sprzętu, zwłaszcza dysków, na których zainstalowany jest system. Warto zaznaczyć, że Proxmox używa własnego jądra Linuksa i zaleca się usunięcie pozostałych.

Po zakończeniu instalacji Proxmoxa czas wyłączyć domyślnie włączone usługi RPC bind działające na porcie 111. Jeśli jesteś w niemieckim internecie, musisz odciąć je od sieci, ponieważ jest to wymóg rządowy. Ponieważ w konfiguracji testowej tego nie potrzebujemy, możemy przejść dalej do konfiguracji sieci. Jeśli używamy tylko sieci publicznej i vSwitcha, potrzebujemy mostka, routingu publicznego IP oraz sekcji VLAN. Gdybyśmy używali dodatkowej lokalnej sieci LAN lub VLAN albo osobnego, fizycznego, dedykowanego przełącznika, trzeba by dodać tu kolejne sekcje. Sprawdź swoją konfigurację dwa, a nawet trzy razy – po przeładowaniu sieci musi działać. W przeciwnym razie trzeba będzie skorzystać ze zdalnej konsoli szeregowej, co czasem trwa nawet do godziny. Osobiście wolę spójny schemat nazewnictwa serwerów, VLAN-ów i podsieci, jak zapewne zauważysz. Pamiętaj, aby w sekcji VLAN uwzględnić MTU 1400. Po restarcie usługi sieciowej sprawdź łączność lokalną i zewnętrzną.

Jako ciekawostkę próbujemy zaimportować CA Proxmoxa do magazynu certyfikatów przeglądarki, aby mieć czystą kłódkę SSL bez żadnych ostrzeżeń bezpieczeństwa. Aby to zadziałało, nazwa common name certyfikatu musi być ustawiona w /etc/hosts. Później skonfigurujemy HAProxy przez OpenVPN.

Pierwszą konfiguracją, jaką przeprowadzimy, jest konfiguracja firewalla. Umieszczam adresy VLAN, LAN i publiczne adresy IP4 w sekcji Datacenter-Firewall, która będzie stosowana na wszystkich węzłach klastra Proxmox. Oczywiście jeśli dodamy kolejne węzły. Konfiguracją na poziomie Datacenter jest wtedy znacznie łatwiej zarządzać. Firewall zostanie włączony dopiero po przejściu do Firewall-Options i zaznaczeniu go jako włączonego. Pamiętaj, aby dodać własny publiczny adres IP4, żeby nie odciąć sobie połączenia.

Firewall/router pfSense #

11:54: Do obsługi ruchu publicznego instaluję router/firewall pfSense, który można rozszerzyć o dodatkowe pakiety zapewniające szeroki zakres funkcji, takich jak VPN, IDS/IPS itp. Zaczynamy od wgrania pfSense 2.7 CE, co będzie również wymagało aktualizacji. Zanim przejdę dalej, sprawdzam stan dysków za pomocą interfejsu SMART. I szybko inicjalizuję trzeci dysk jako katalog, potrzebny do przyszłej instalacji PBS. Wgrywam też obraz ISO PBS oraz obraz ISO Ubuntu.

Tworzymy nową VM z podstawowymi ustawieniami. Ważne jest, aby mieć co najmniej jedną kartę sieciową. Pierwsza będzie dla interfejsu WAN, a druga dla VLAN, gdzie ustawiamy MTU 1400. Na WAN ustawiamy wirtualny adres MAC utworzony wcześniej w portalu Robot. Jeśli uruchamiasz VM na serwerze, posiadanie go na WAN jest krytyczne. Brak tego ustawienia spowoduje ostrzeżenie Hetznera o „wyciekaniu” adresów MAC (MAC bleeding), a nawet blokadę serwera. Instalacja pfSense jest prosta. Wybieramy wszystkie ustawienia domyślne. Ponieważ do mirrorowania dysków używamy md, nie ma potrzeby konfigurowania tej redundancji dla pfSense. Po restarcie pfSense prosi o konfigurację sieci, zarówno dla interfejsu LAN, jak i WAN. Trzeba ją dostosować. Na początku UI jest dostępny przez WAN, ponieważ nie mamy możliwości wejścia do LAN/VLAN. Można by przygotować VM typu sandbox, z której dałoby się uzyskać dostęp do sieci lokalnej, ale w tej konfiguracji testowej będziemy korzystać z WAN, dopóki nie skonfigurujemy OpenVPN. Po każdej większej zmianie konfiguracji pfSense dobrą praktyką jest jego restart.

Korzystanie z WAN bez skonfigurowanych reguł oznacza, że trzeba wykonać pfctl -d, aby wyłączyć firewall. Zaloguj się domyślnymi danymi i przejdź przez konfigurację krok po kroku w UI. Możesz zmienić ustawienia DHCP dla WAN i jawnie podać domyślną bramę WAN, ponieważ wygląda na to, że nie jest ustawiona.

Dashboard pfSense, czyli stronę główną, można wzbogacić o kilka efektownych wykresów dotyczących statystyk usług i sieci. Główną konfigurację można przeprowadzić w System – General Setup lub w ustawieniach Advanced. Ustawiamy domenę, strefę czasową i konfigurację DNS. Na potrzeby późniejszego HAProxy trzeba wyłączyć automatyczne przekierowanie portu WebGUI, nawet jeśli działa on na porcie innym niż standardowy, co jest dobrą praktyką zarówno dla UI, jak i usług OpenVPN działających na tym urządzeniu.

Aby korzystać z OpenVPN, musimy utworzyć certyfikat CA, by móc podpisać certyfikat serwera. Następnie tworzymy certyfikat. Potem tworzymy regułę przepuszczającą ruch na port serwera OpenVPN. Następnie przechodzimy do Services-OpenVPN i dodajemy nowy serwer OpenVPN w konfiguracji SSL/TLS + User Auth, wyłącznie na TCP IP4. Pamiętaj, aby wskazać certyfikat serwera – łatwo to przeoczyć albo nawet wybrać jakiś certyfikat użytkownika. Ustaw adresację sieci tunelu dla klientów oraz sieć lokalną, która będzie routowana do środowiska. Dobrze jest zachować spójną numerację podsieci tunelu, a także ustawić liczbę jednoczesnych połączeń na jakąś niższą wartość, aby szybko zidentyfikować ewentualne nadużycia.

Aby korzystać z OpenVPN, potrzebny będzie użytkownik z certyfikatem użytkownika. Najpierw utwórz użytkownika, a potem jego certyfikat. Teraz nadchodzi dziwaczna część, czyli instalacja dodatkowych pakietów pfSense na nieaktualnym systemie bazowym. Pojawia się komunikat o błędzie, który prowadzi nas do ustawienia System-Update. Metodą prób i błędów wiem, że najpierw trzeba zaktualizować system, ale różni się to w zależności od wersji. Tym razem nie zadziałała u mnie ani aktualizacja przez UI, ani przez konsolę. Rozwiązaniem był rehash certyfikatów. W różnych wcześniejszych wersjach były inne rozwiązania podobnych problemów z kompatybilnością. Zrobienie tego niewłaściwie mogłoby uceglić system, więc przed rozpoczęciem takiej sesji troubleshootingu upewnij się, że masz backup.

W końcu, po rehashu certyfikatów, możemy przejść do aktualizacji. Bez aktualizacji pakiety nie były dostępne. Ten proces aktualizacji trwa kilka minut.

Jak zaimportować konfigurację użytkownika OpenVPN do Ubuntu? Albo przez GUI, albo za pomocą narzędzia nmcli. Uważam, że to drugie jest łatwiejsze i stabilniejsze w różnych wcześniejszych wersjach Ubuntu. Nawet po zaimportowaniu konfiguracji nadal trzeba podać nazwę użytkownika, hasło i zaznaczyć opcję Use this connection only for resources on its network. Aby korzystać z połączeń przez interfejs OpenVPN, musimy dodać odpowiednie reguły przepuszczające. Jeśli chcesz diagnozować łączność za pomocą ping, pamiętaj, aby przepuścić również ruch ICMP. Sprawdź, czy klient OpenVPN jest połączony i czy utworzyłeś już regułę ICMP, a jeśli nadal nie działa, zrestartuj urządzenie, aby skrócić czas zastosowania konfiguracji.

HAProxy #

19:10: Dostęp do serwera Proxmox można uzyskać za pomocą HAProxy. Najpierw definiujemy backend, czyli serwer docelowy na porcie 8006. Ponieważ na razie nie mamy możliwości równoważenia obciążenia, lepiej wyłączyć health checki. Następnie definiujemy frontend na jakimś niestandardowym porcie na interfejsie LAN, z typem działania TCP i backendem ustawionym na ten, który skonfigurowaliśmy przed chwilą. W ustawieniach musimy włączyć HAProxy, zdefiniować maksymalną liczbę połączeń, ustawić wewnętrzne porty statystyk i na koniec ustawić maksymalny rozmiar parametru SSL DH.

Dobrze jest posprzątać nieużywaną regułę firewalla.

Wybieramy port 9443 dla UI Proxmoxa i od teraz nie musimy używać publicznego interfejsu WAN, aby się do niego dostać, ponieważ mamy dostępne tunelowane połączenie OpenVPN. Po co w ogóle ustawiać HAProxy dla UI Proxmoxa? Ponieważ Proxmox sam nie jest routowany przez pfSense, który oferuje OpenVPN, trzeba się do niego dostać albo przez WAN, albo przez NAT-proxy, albo przez to, co właśnie zrobiliśmy, czyli konfigurację HAProxy.

Teraz, gdy mamy zabezpieczone połączenie z UI Proxmoxa, czas skonfigurować 2FA z TOTP. Kilka zastrzeżeń w tej kwestii: jeśli chcesz utworzyć klaster, a następnie dodać do niego kolejny serwer (musi być pusty, bez VM/kontenerów), musisz wyłączyć 2FA, dodać serwer do klastra, a potem włączyć je ponownie. Co więcej, najprawdopodobniej trzeba będzie zrestartować usługę pvestatd, ponieważ w większości przypadków traci synchronizację.

Suricata – system bezpieczeństwa IDS/IPS #

21:03: Lista interfejsów jest na starcie pusta, więc trzeba jakiś utworzyć, konkretnie dla interfejsu WAN. Ważne jest tu włączenie opcji Block Offenders w trybie Legacy, blokującej źródłowy adres IP. Jeśli chodzi o czułość detect-engine, wolę ustawić ją na Medium lub High. W kwestii reguł i ich kategorii są dwa podejścia. Pierwsze mówi, że należy wyłączyć reguły techniczne dotyczące przepływów itp., co na pewno zmniejszy liczbę blokad false-positive. Jednak w ten sposób wpuścimy znacznie więcej nieprawidłowego ruchu. Jest więc drugie podejście, w którym zostawiamy je włączone i ręcznie zajmujemy się blokadami false-positive. Polecam włączenie niemal wszystkich kategorii EP Open Rules. Najważniejsze jest tu wejście do zestawu reguł emerging-scan i włączenie wszystkich typów skanów nmap, ponieważ z nieznanego mi powodu są domyślnie wyłączone. W ten sposób będziemy w stanie blokować najpopularniejsze skany. To samo dotyczy zestawu reguł emerging-icmp.

Aby spełnić wymagania różnych polityk i standardów bezpieczeństwa, dobrze wiedzieć, że istnieje możliwość wydłużenia okresu retencji logów do, powiedzmy, 3 miesięcy. Możemy też wysyłać logi do zdalnego sysloga, konfigurując to bezpośrednio w Suricacie lub w ogólnych ustawieniach pfSense. W tym momencie możemy włączyć i uruchomić Suricatę działającą na naszym interfejsie WAN. Na zakładce alertów możemy monitorować powiadomienia bezpieczeństwa, a także bezpośrednio odblokowywać źródłowe adresy IP. Na zakładce blokad znajduje się lista wszystkich aktualnie zablokowanych adresów IP, skąd możemy je odblokować lub sprawdzić, czy zdarzyło się to już w przeszłości, ponieważ jest tam lista wcześniejszych incydentów.

Nie minęła nawet minuta, a na liście pojawiły się pierwsze incydenty. Jeden pochodzi z technicznego zestawu reguł, takiego jak weryfikacja poprawności pakietów TCP, a dwa pozostałe z zestawów reguł scan i spamhouse z ET. Oznacza to, że zostaliśmy zarówno przeskanowani, jak i odwiedzeni przez podmiot wpisany do katalogu Spamhaus, ściśle mówiąc do grupy 9. Uruchomienie Suricaty na kilkudziesięciu maszynach przez kilka miesięcy da nam miliony przeróżnych alertów i blokad. Czasami źródłowe adresy IP będą się powtarzać w różnych lokalizacjach, co oznacza, że ktoś skanuje całe bloki IPv4, celuje w dostawcę internetu albo celuje dokładnie w Ciebie jako osobę lub organizację utrzymującą te maszyny. Na zakładce alertów możesz sprawdzić odwrotny DNS dla adresów IP, a także spróbować je geolokalizować. Może to być przydatna informacja lub nie, w zależności od potrzeb analizy powłamaniowej w Twoim przypadku biznesowym.

Przy łączeniu systemów, czy to przez interfejs publiczny, czy przez tunel VPN, często zdarza się, że systemy wzajemnie się „diagnozują” i nakładają blokady. Aby uniknąć takiej sytuacji, jest zakładka pass list, na której możesz wpisać publiczne adresy IP swoich systemów, aby zapobiec ich blokowaniu. Po utworzeniu listy pass list zawierającej zewnętrzne publiczne adresy IP możesz przypisać ją do interfejsu na stronie edycji interfejsu.

VM z Ubuntu #

24:44: Krótkie podsumowanie: kupiliśmy, a właściwie wynajęliśmy serwer dedykowany, zainstalowaliśmy Debiana, Proxmoxa, pfSense, HAProxy, a teraz stajemy przed utworzeniem VM z Ubuntu, która później będzie pełnić rolę węzła master/worker Docker Swarm, zarządzanego przez narzędzie do orkiestracji Portainer CE. Utworzenie nowej VM jest proste, bo ograniczamy się do podstaw. Jeśli jednak chodzi o instalację Ubuntu Server, jest kilka opcji. Przede wszystkim możemy użyć HashiCorp Packera, a nawet Terraforma, ponieważ istnieje provider dla Proxmoxa 7. Co więcej, zamiast ręcznie tworzyć obraz instalacyjny, moglibyśmy przygotować konfigurację autoinstall lub cloud-init, która zrobi to automatycznie. Na potrzeby tego filmu zrobię to ręcznie. Ważne jest, aby każdy dysk systemowy u dowolnego dostawcy, łącznie z Twoim domem, był zabezpieczony szyfrowaniem, np. LUKS. Na ten temat znajdziesz artykuł na moim blogu. Dla wygody wolę ręcznie wpisywać hasło LUKS do odszyfrowania dysku. Są też inne opcje, ale wymagają dodatkowego oprogramowania lub sprzętu.

Po rozpakowaniu i instalacji systemu bazowego trzeba zainstalować kilka dodatkowych pakietów oraz pobrać i zastosować aktualizacje. Zajmie to chwilę, w zależności od wybranego sprzętu.

Instalacja systemu jest zakończona, możemy wysunąć obraz ISO, zrestartować maszynę i przetestować odszyfrowanie LUKS dysku systemowego.

Docker Swarm + Portainer #

26:55: Tę sekcję zaczynamy od instalacji usługi i narzędzi Docker-CE, ponieważ są one kluczowym elementem konfiguracji Docker Swarm z Portainerem używanym do orkiestracji kontenerów. Gdy szukam sprawdzonych i dobrze przetestowanych poradników instalacyjnych, często zaglądam na stronę DigitalOcean, świetnego dostawcy chmury obliczeniowej, z którego korzystam od ponad dekady, odkąd przeszedłem do niego z Rackspace. W tamtym czasie, około 2010 roku, te firmy dobrze startowały, ale dość szybko zostały wyprzedzone (w dziedzinie rozwiązań chmury publicznej) przez Google, Microsoft i Amazon i zamiast ostro konkurować, zdecydowały się na inne podejścia biznesowe, aby utrzymać się na rynku.

Po zainstalowaniu usługi Docker-CE możemy przejść do inicjalizacji Docker Swarm. Zanim jednak to zrobimy, trzeba ręcznie utworzyć sieci docker_gwbridge i ingress, tuż przed uruchomieniem docker swarm init. Dlaczego, zapytasz? Otóż dlatego, że Hetzner wymaga MTU 1400, a Docker nie obsługuje zmiany MTU w locie i nie podąża za ustawieniami sieci hosta. Możesz więc albo zostawić sieci tak, jak są, ale nie używać vSwitcha, albo używać mapowania portów wyłącznie w trybie host, co spowoduje powiązanie z kartą sieciową hosta zamiast z ingress. Jednak w rzeczywistych zastosowaniach dobrze jest mieć możliwość utworzenia Docker Swarm z więcej niż jednym węzłem, co najmniej 3 węzłami master (wymagana nieparzysta liczba) i również 3 węzłami worker. Taka konfiguracja może być rozłożona na kilka różnych fizycznych maszyn połączonych przez vSwitch w Hetznerze, który działa z prędkością maksymalnie 1 Gpbs. Nawet jeśli nie planujesz podobnej konfiguracji, dobrze jest mieć MTU ustawione na właściwą wartość, bo w przeciwnym razie będziesz męczyć się z migracjami usług, gdy Docker Swarm będzie już zainicjalizowany i używany produkcyjnie.

Teraz o Portainerze CE, czyli UI do zarządzania kontenerami Docker, konfiguracjami Swarm i wieloma, wieloma innymi rzeczami. Dostępna jest też edycja biznesowa z jeszcze większą liczbą funkcji. Gorąco polecam, zwłaszcza jeśli szukasz sprytnych i prostych rozwiązań dla swoich kontenerów, a męczysz się z OpenShift/OKD/Kubernetes. Mam komercyjne doświadczenie z nimi wszystkimi, więc mogę powiedzieć, że duetowi Docker Swarm i Portainer brakuje pewnych rzeczy, ale te braki można łatwo uzupełnić innymi rozwiązaniami. Jeśli chodzi o instalację, po prostu pobierasz plik YML z konfiguracją kontenerów itd. Ponieważ te elementy, czyli UI i agent, będą działać w niestandardowej sieci, przed wdrożeniem trzeba również dostosować MTU w tym pliku konfiguracyjnym.

Pobranie obrazów i uruchomienie ich w Dockerze trwa około minuty. UI jest dostępny na porcie 9443. Na początku tworzysz użytkownika z hasłem i jesteś w środku. Podstawowym środowiskiem jest środowisko lokalne, a ponieważ Portainer działa z lokalnym wolumenem, powinien pozostać na tym konkretnym węźle. Agent jest natomiast wdrażany z parametrem global, co oznacza, że zostanie wdrożony na każdym dostępnym węźle klastra Docker Swarm.

Teraz czas na kontener hello world w naszym świeżo zainstalowanym środowisku wirtualizacji i kontenerów. Są dwa rodzaje obrazów testowych. Pierwszy służy do sprawdzenia, czy cokolwiek w ogóle działa, i nazywa się hello-world. Sprawdza, czy Docker potrafi pobierać obrazy z internetu lub innej sieci i czy uruchamianie kontenerów działa. Ponieważ nie ma żadnego długotrwałego zadania, będzie się zapętlał po każdym uruchomieniu. Dobrze jest więc przetestować coś bardziej użytecznego, na przykład nginx.

Nginx to serwer HTTP, więc warto teraz skonfigurować mapowanie portów, które wykorzysta wewnętrzną sieć Docker Swarm o nazwie ingress. Pobranie obrazu i jego uruchomienie trwa kilka sekund. Już w przeglądarce, na wybranym porcie, możemy sprawdzić, czy usługa faktycznie działa. I działa. Jest to jednak połączenie w sieci lokalnej, dostępne tylko przez tunel OpenVPN. Aby udostępnić ten serwer Nginx w publicznym internecie, możemy użyć HAProxy. Przy ruchu niskim i średnim, czyli do 20 tysięcy jednoczesnych użytkowników, wystarczy pojedyncza instancja HAProxy na pfSense, ponieważ jest wystarczająca pod względem wydajności, konfiguracji itp. W przypadku większych wdrożeń polecałbym dynamiczny DNS, taki jak dostępny na scaleway.com, wiele maszyn pfSense z osobnymi publicznymi adresami IP i osobne HAProxy, czy to na pfSense, czy również oddzielnie.

Tym razem zamiast typu przetwarzania TCP, jak w przypadku UI Proxmoxa, użyjemy http / https (offloading), co pozwoli szyfrować ruch, który jest przekazywany przez reverse proxy do serwera backendowego bez szyfrowania, ponieważ na razie nie zapewniamy szyfrowania po stronie nginx. Jaka jest korzyść z przeniesienia obsługi TLS na maszynę pfSense? Po pierwsze, jest mniej konfiguracji do zarządzania, ponieważ albo wprowadzamy certyfikat do magazynu certyfikatów, albo używamy ACME, na przykład z LetsEncrypt. Po drugie, oddziela to po prostu punkt wejścia do środowiska od wnętrza systemu w sieci lokalnej.

Ponieważ HAProxy działa teraz na interfejsie WAN, trzeba utworzyć regułę firewalla dla wszystkich portów używanych w naszej konfiguracji. Ta konfiguracja testowa obejmuje tylko ruch nieszyfrowany. Ruch szyfrowany będzie wymagał również reguły przepuszczającej HTTPS oraz przekierowania schematu (redirect scheme) na frontendach HAProxy. Dobrą praktyką w pfSense jest porządkowanie reguł za pomocą separatorów – po prostu wszystko staje się wtedy znacznie bardziej przejrzyste. Pamiętaj, aby albo zapewnić właściwy health check i mieć wiele backendów, albo po prostu wyłączyć tę funkcję, jeśli masz tylko jeden backend.

Proxmox Backup Server #

33:44: Ostatnim tematem w naszej konfiguracji testowej jest backup, który jest bardzo ważny niezależnie od funkcjonalności samego środowiska. Zaczynamy od utworzenia VM dla PBS z podstawowymi ustawieniami. Systemem jest Debian i nie wymaga on dużej partycji root, ale wymaga sporo pamięci, co będzie jeszcze ważniejsze, jeśli mamy wolne dyski. Pamiętaj, że szyfrowanie backupów odbywa się po stronie klienta w Proxmoxie. Instalacja PBS jest prosta, bez żadnych niespodzianek. Na razie mamy tylko jeden dysk, przeznaczony na system.

Po zakończeniu instalacji dodajemy kolejny dysk, który będzie używany jako magazyn backupów. Pamiętaj, aby odznaczyć pole backup. Dysk możemy dodać na żywo, podczas działania systemu. Najprostszą opcją jest utworzenie katalogu, który zostanie zamontowany z systemem plików ext4 lub xfs. W zależności od rozmiaru dysku proces inicjalizacji potrwa od minuty do mniej więcej 15 minut.

Aby dodać PBS do Proxmox VE, przejdź na poziom Datacenter – Storage i utwórz nowy wpis z integracją PBS. Nazwa użytkownika wymaga dopisania @pam. Trzeba też podać nazwę datastore’a, który właśnie utworzyliśmy. Na koniec, aby autoryzować integrację, musisz skopiować fingerprint z UI PBS. Po dodaniu integracja PBS z datastore’em będzie widoczna w sekcji storage na wybranych węzłach.

Aby utworzyć zadanie backupu, przejdź do Datacenter-Backup. Możesz wybrać między backupem lokalnym a backupem do PBS. Najpierw definiujemy, co ma być backupowane i według jakiego harmonogramu. Bardzo ważne jest skonfigurowanie szyfrowania po stronie klienta, co można zrobić, edytując integrację PBS na zakładce Encryption. Wygeneruj klucz automatycznie i zabezpiecz go, przechowując bezpiecznie w co najmniej 2 lokalizacjach, również w formie zaszyfrowanej.

Najpierw testujemy zadanie backupu, uruchamiając backup bezpośrednio na dysk lokalny, co będzie kopią lokalną. Powinno to działać znacznie szybciej niż przez PBS, więc w niektórych przypadkach może to być sposób na wykonanie backupu, gdy nie możesz pozwolić sobie na obciążenie pamięci lub sieci. Co więcej, jest to jedna z metod posiadania oddzielnych backupów na różnych nośnikach. Oczywiście w przypadku, gdy PBS jest na osobnym dysku, tak jak tutaj. Możemy teraz odhaczyć pierwszy wymóg ze standardowej polityki backupu i ochrony danych – posiadanie oddzielnych fizycznych kopii.

Idąc nieco dalej w temacie backupu, standardów i polityk, tworzymy drugi serwer backupu, również z PBS. Na potrzeby testu oczywiście trzymamy go w tej samej lokalizacji, ale w rzeczywistości będzie to inna lokalizacja fizyczna, a nawet inny klaster Proxmox. Celem jest wykonywanie backupu do głównego PBS i synchronizowanie go z drugim serwerem PBS. W ten sposób możemy osiągnąć różne poziomy backupu i ochrony danych. Możemy zróżnicować retencję backupów na serwerze głównym i synchronizowanym, decydując, gdzie trzymać więcej, w zależności od tego, gdzie mamy więcej miejsca do przeznaczenia na backupy.

Na drugim PBS tworzymy wszystko w ten sam sposób. Pierwszą nową rzeczą jest dodanie Remote, czyli naszego serwera źródłowego, z którego będziemy pobierać fragmenty (chunki) backupów. Mając skonfigurowany remote, przechodzimy do zakładki Sync Jobs, gdzie definiujemy, jak często synchronizować i jak długo przechowywać zsynchronizowane backupy. Zarówno dla głównego, jak i dodatkowego serwera backupu zaleca się skonfigurowanie prune po stronie serwerów. To samo dotyczy zadań garbage collection. Pamiętaj, że GC przechowuje chunki przez kolejne 24 godziny, nawet gdy prune usunął już sam backup. Tak to po prostu działa, więc mając to na uwadze, musimy właściwie zaplanować pojemność pod kątem liczby przechowywanych kopii.

Mamy teraz backupy lokalne, zdalne oraz zsynchronizowane na 3 nośnikach. Na razie powinniśmy być bezpieczni, oczywiście jeśli serwer synchronizacji znajdowałby się poza tym serwerem.

Podobnie jak w Proxmoxie, również w PBS możemy skonfigurować 2FA TOTP.