Proxmox VE i pfSense na serwerach dedykowanych Hetznera

Przetłumaczone automatycznie z angielskiego. Przeczytaj oryginał

Hetzner nie udostępnia zbyt wiele precyzyjnej dokumentacji, jeśli chcesz wiedzieć, co dokładnie zrobić, aby uruchomić serwery dedykowane z głównym i dodatkowym publicznym IP, maszynami wirtualnymi i vSwitchem. Jest kilka artykułów, ale są napisane mało konkretnie. Za to ich wsparcie stoi jak dotąd na bardzo wysokim poziomie, odpowiadają szybko.

Instalacja Debiana & Proxmoxa #

Aby więc uruchomić Proxmoxa na Hetznerze, musisz wiedzieć, że istnieje wspierana instalacja. Restartujesz serwer do systemu ratunkowego (rescue system; pamiętaj o wyłączeniu i włączeniu zasilania serwera), a tam jest do wyboru Proxmox, ale z zastrzeżeniem, że nie ma dla niego wsparcia, tak jak dla innych systemów… Jeśli bawisz się dość złożonym środowiskiem, sam powinieneś być przygotowany na pokonanie wszystkich przeszkód, nie polegając na stronach trzecich. Jesteś więc w systemie ratunkowym i zamiast wybrać Proxmoxa, wybierasz instalację najnowszego Debiana.

W przypadku Debiana wyłączasz programowy RAID, bo może być – i będzie – niekompatybilny z ZFS w późniejszym etapie. Wpisujesz swoją nazwę domeny zarejestrowaną w publicznym DNS. Późniejsza zmiana domeny będzie trudna, żeby nie powiedzieć, że może być niemożliwa (z perspektywy Proxmoxa). W zależności od konfiguracji dysków w serwerze możesz chcieć dostosować konfigurację punktów montowania. Ja wolę umieścić Proxmoxa na mniejszym dysku i przydzielić całą dostępną przestrzeń do punktu montowania root, zamiast tworzyć różne mniejsze punkty montowania. Kiedy skończysz, zapisz zmiany (F10) i poczekaj, aż pojawi się prośba o restart.

Po restarcie serwera zainstalujesz na nim Proxmoxa:

Bash
echo "deb [arch=amd64] http://download.proxmox.com/debian/pve bullseye pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list
wget https://enterprise.proxmox.com/debian/proxmox-release-bullseye.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bullseye.gpg 
apt update && apt full-upgrade
apt install proxmox-ve postfix open-iscsi
systemctl reboot
apt remove linux-image-amd64 'linux-image-5.10*'
update-grub
apt remove os-prober
systemctl reboot

Konfiguracja sieci #

Interfejs Proxmox VE będzie dostępny pod Twoim publicznym IP, na porcie 8006. Następnie przejdź do panelu Hetznera i utwórz nową instancję vSwitch. Dodaj swój serwer do nowo utworzonego vSwitcha. Zastosowanie konfiguracji sieci trwa w Hetznerze około minuty. W Proxmoxie przejdź do ustawień węzła, wybierz System – Network i utwórz dwa puste bridge'e, nazwij je vmbr0 i vmbr1. Pierwszy jest dla głównego publicznego IP, które będzie używane wyłącznie do dostępu do Proxmoxa. Drugi jest dla LAN-u, ponieważ każda maszyna wirtualna i kontener będzie miał własne IP widoczne tylko w obrębie serwera. Dla VLAN-u na vSwitchu utworzymy bridge i VLAN ręcznie w /etc/network/interfaces nieco później. Po utworzeniu tych dwóch bridge'y zastosuj konfigurację i zrestartuj serwer.

W pliku interfaces usuń IPv6 i wszelkie komentarze. Przede wszystkim w większości przypadków nie będziesz potrzebować IPv6. Jeśli Twoja konfiguracja wymaga „publicznego” IPv6, to na razie nie będę próbował niczego w tej kwestii doradzać. Uważam, że jest bardzo przydatne w takich rzeczach jak IoT czy sieci komórkowe, ale dla zwykłych serwerów konsumenckich już niekoniecznie. Możesz mieć inne zdanie i to w porządku, ja wyłączam IPv6 z przyzwyczajenia. Na przykład mój dostawca internetu nie oferuje łączności IPv6.

Mamy więc teraz dwa puste bridge'e i usunięte IPv6. Pora skonfigurować główne i dodatkowe publiczne IPv4, a także LAN i VLAN. Zaczynajmy. Nazwy urządzeń Ethernet zaczynają się od „en”, po którym następuje „p” dla magistrali PCI z kolejnym numerem N, a następnie „s” dla slotu i jego numer. Na przykład enp5s0 można zidentyfikować jako Ethernet na PCI numer 5, slot 0. Istnieją też inne konwencje nazewnictwa dla urządzeń WLAN i WWAN, a także różne źródła tych nazw, np. oparte na BIOS-ie lub jądrze.

Bash
source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

iface lo inet6 loopback

auto enpNs0
iface enpNs0 inet manual

Dalsza część pliku konfiguracji sieci dla bridge'a vmbr0, używanego dla głównego i dodatkowego publicznego IP:

Bash
auto vmbr0
iface vmbr0 inet static
  address 65.109.x.x/MASK
  gateway 65.109.x.x
  pointopoint 65.109.x.x # same as gateway
  bridge-ports enpNs0 # device name
  bridge-stp off
  bridge-fd 0
  up route add -net 65.109.x.x netmask 255.255.255.x gw 65.109.x.x dev vmbr0 # main IP route
  up ip route add 65.109.x.x/32 dev vmbr0 # additional IP route
  post-up ip route add x.x.x.0/24 via 65.109.x.x dev vmbr0 # LAN network via additional IP

Najpierw kilka słów wyjaśnienia. Address to Twój główny publiczny IPv4. Gateway i pointopoint są tu takie same. Pierwsza dodana trasa to domyślna, która pochodzi z procesu instalacji, więc po prostu ją tu skopiuj (powinna być taka sama jak w portalu administracyjnym Hetznera). Druga trasa definiuje dodatkowy publiczny adres IPv4. Ostatnia to wybrana przez Ciebie sieć LAN, która jest przekazywana przez vmbr0 i dodatkowy adres IPv4 do świata zewnętrznego.

Ta sieć LAN jest skonfigurowana jako pusty bridge, a cała wymagana konfiguracja odbywa się wewnątrz urządzenia bramy (np. pfSense) i samej maszyny wirtualnej:

Bash
auto vmbr1
iface vmbr1 inet manual
	bridge-ports none
	bridge-stp off
	bridge-fd 0

Ostatnia sekcja pliku konfiguracji sieci dotyczy VLAN-u:

Text
iface enpNs0.400X inet manual
auto vmbr400X
iface vmbr400X inet manual
	address 10.x.x.1/16 # VLAN gateway and network range
	bridge_ports enp41s0.400X
	bridge_sftp off
	bridge_fd 0
	mtu 1400 # important to have

Tworzymy linuksowe urządzenie VLAN i bridge. Definiujemy adres, który będzie używany jako lokalna brama do komunikacji z maszynami poza tym serwerem. Wymagane jest ustawienie MTU na 1400.

Wirtualny MAC na pfSense #

Dla LAN-u w obrębie pojedynczego serwera oraz łączności ze światem zewnętrznym (internetem) używamy bramy pfSense. Konfiguracja jest prosta, dajemy jej dwa interfejsy sieciowe. Pierwszy jest dla WAN-u z dodatkowym publicznym IPv4. Musimy poprosić o wirtualny MAC w panelu administracyjnym Hetznera. Drugi interfejs jest dla LAN-u i może mieć automatycznie wygenerowany adres MAC. Wszystkie maszyny wirtualne w LAN-ie powinny mieć adresy w sieci zdefiniowanej w vmbr1, z bramą ustawioną na lokalny pfSense. Do komunikacji między serwerami w obrębie VLAN-u dajemy maszynie wirtualnej dodatkowy interfejs sieciowy skierowany na urządzenie vmbr400X i ustawiamy sieć w zakresie zdefiniowanym na tym bridge'u, wskazując IP bridge'a jako bramę.

Jedna brama dla kilku fizycznych serwerów #

Wspomniałem wcześniej, że dla swoich maszyn warto używać zarówno LAN-u, jak i VLAN-u, jednak możesz zdecydować się na inne rozwiązanie. Możesz skonfigurować pojedynczą bramę pfSense z LAN-em i VLAN-em i skierować trasy innych maszyn wirtualnych na adres VLAN tego pfSense. Trzeba pamiętać, że należy ustawić MTU na 1400. Każda inna wartość da dziwne rezultaty, np. ping i DNS będą działać, ale większe transfery już nie, bo przekraczają limit pakietu dozwolony na vSwitchu. Ustawienie właściwej wartości MTU pozwoli więc kierować wychodzący ruch internetowy przez pojedynczy pfSense. To dyskusyjna konfiguracja, bo ma pojedynczy punkt awarii. Inną wadą jest to, że musisz pilnować publicznych adresów IPv4, których chcesz używać na swojej pojedynczej bramie, ponieważ takie IP jest powiązane z konkretnym serwerem w Hetznerze poprzez adres MAC. Może jest na to jakieś rozwiązanie, ale na razie nie.

Uwaga: Taka konfiguracja wymaga dodania trzeciej karty sieciowej do bramy pfSense.

Wersja Markdown

Wszystkie treści na tej stronie są udostępniane na licencji Uznanie autorstwa – Użycie niekomercyjne – Bez utworów zależnych 4.0 Międzynarodowe (CC BY-NC-ND 4.0). Cytuj jako: Michał Sobczak, „Proxmox VE i pfSense na serwerach dedykowanych Hetznera”, 8 listopada 2022, https://michalasobczak.pl/pl/posts/proxmox-ve-on-hetzner-dedicated-servers.html