Prywatny klaster VPS na siatce WireGuard

Krótko: aby zamienić kilka VPS w prywatny klaster, nadaj każdemu węzłowi VPS interfejs WireGuard z adresem z jednej prywatnej podsieci, dodaj każdy inny węzeł jako `[Peer]` z jego publicznym `Endpoint` i `/32` w `AllowedIPs`, zezwól na UDP 51820 tylko z własnych węzłów i przypnij bazy danych oraz usługi wewnętrzne do adresu `wg0` zamiast publicznego IP. Do około dziesięciu węzłów łatwo to utrzymać ręcznie lub z szablonu; powyżej tego używaj narzędzi, które generują i dystrybuują konfiguracje.

Ten poradnik zakłada, że znasz już podstawy z poradnika o VPN WireGuard i masz zabezpieczone SSH na każdym węźle jak w poradniku o hardeningu SSH; aby docierać do węzłów przez bastion bez przekazywania agenta, zobacz poradnik o StrictModes i przekazywaniu agenta.

Plan adresacji węzłów VPN

Wybierz jeden prywatny zakres, który nie koliduje z niczym innym, czego używasz (domowy LAN, Docker, zakresy podów Kubernetes). `/24` wystarczy dla małego klastra i zachowuje czytelność adresów. Przypisz każdemu węzłowi stały adres i trzymaj plan w systemie kontroli wersji, bo każda konfiguracja jest z niego wyprowadzana.

Konfiguracja peerów na każdym węźle VPS

W pełnej siatce każdy węzeł rozmawia bezpośrednio z każdym innym, więc każda konfiguracja ma jedną sekcję `[Interface]` i N-1 sekcji `[Peer]`. Cztery węzły to łącznie sześć tuneli; dziesięć węzłów to 45. Każdy węzeł ma publiczny IP, więc `PersistentKeepalive` zwykle nie jest potrzebny; szczegóły w poradniku o keepalive i PresharedKey.

1. 01.Na każdym węźle uruchom `apt install wireguard`, a potem `umask 077; wg genkey | tee /etc/wireguard/wg0.key | wg pubkey > /etc/wireguard/wg0.pub`.
2. 02.Zbierz wszystkie klucze publiczne i plan adresacji w jednym miejscu.
3. 03.Opcjonalnie wygeneruj jeden klucz `wg genpsk` na parę węzłów jako zabezpieczenie postkwantowe.
4. 04.Napisz `/etc/wireguard/wg0.conf` na każdym węźle, jak pokazano poniżej.
5. 05.Uruchom `systemctl enable --now wg-quick@wg0` i sprawdź w `wg show`, czy z każdym peerem jest niedawny handshake.

# /etc/wireguard/wg0.conf on node1
[Interface]
Address = 10.88.0.1/24
ListenPort = 51820
PrivateKey = <node1 private key>

[Peer]
# node2
PublicKey = <node2 public key>
Endpoint = 203.0.113.12:51820
AllowedIPs = 10.88.0.2/32

[Peer]
# node3
PublicKey = <node3 public key>
Endpoint = 203.0.113.13:51820
AllowedIPs = 10.88.0.3/32

[Peer]
# node4
PublicKey = <node4 public key>
Endpoint = 203.0.113.14:51820
AllowedIPs = 10.88.0.4/32

Jak działa AllowedIPs w siatce

`AllowedIPs` pełni jednocześnie dwie funkcje. Dla ruchu wychodzącego jest tablicą routingu: pakiety do `10.88.0.3` trafiają do peera, który ma `10.88.0.3/32`. Dla ruchu przychodzącego jest listą dostępu: pakiet od tego peera jest przyjmowany tylko wtedy, gdy jego adres źródłowy mieści się w `AllowedIPs` tego peera. Dlatego każdy peer dostaje dokładnie swój własny `/32`, a nie całe `/24`.

`/24` w linii `Address` tworzy jedynie trasę jądra dla podsieci na `wg0`; WireGuard wybiera następnie właściwego peera dla każdego celu.

• ▹Dwa peery na tym samym interfejsie nigdy nie mogą mieć nakładających się zakresów `AllowedIPs`; wygrywa ostatni.
• ▹Jeśli węzeł routuje też prywatną podsieć (np. Docker na node3), dodaj ją do `AllowedIPs` node3 na pozostałych węzłach.
• ▹Nie wpisuj `0.0.0.0/0` dla peera w siatce, chyba że naprawdę chcesz, by cały ruch wychodził przez ten węzeł.

Firewall: do tunelu docierają tylko Twoje węzły

WireGuard nie odpowiada na nieuwierzytelnione pakiety, ale ograniczenie UDP 51820 do znanych IP węzłów i tak zmniejsza szum. Wewnątrz tunelu otwieraj tylko porty potrzebne poszczególnym usługom. Ten przykład nftables dla Debiana 12/13 i Ubuntu 24.04 trafia do `/etc/nftables.conf`; wczytaj go przez `nft -f /etc/nftables.conf` i włącz `nftables.service`. Podczas testów trzymaj otwartą sesję SSH.

table inet filter {
  set mesh_peers {
    type ipv4_addr
    elements = { 203.0.113.11, 203.0.113.12, 203.0.113.13, 203.0.113.14 }
  }
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    meta l4proto { icmp, ipv6-icmp } accept
    tcp dport 22 accept
    udp dport 51820 ip saddr @mesh_peers accept
    iifname "wg0" ip saddr 10.88.0.0/24 tcp dport { 5432, 6379, 9100 } accept
  }
}

Przypnij usługi do interfejsu wg

Firewall to jedna warstwa; druga to w ogóle nie nasłuchiwać na publicznym adresie. Przypnij usługi wewnętrzne do adresu `wg0` węzła, aby błąd w firewallu ich nie wystawił. Ponieważ `wg0` musi istnieć, zanim usługa się podepnie, uporządkuj jednostki przez drop-in systemd albo zezwól na przypinanie do adresów, które jeszcze nie są aktywne, przez `net.ipv4.ip_nonlocal_bind = 1`.

# PostgreSQL on node3: postgresql.conf
listen_addresses = '10.88.0.3'
# pg_hba.conf
host  all  all  10.88.0.0/24  scram-sha-256

# Redis: /etc/redis/redis.conf
bind 10.88.0.3

# systemctl edit postgresql  (repeat for other services)
[Unit]
[email protected]
[email protected]

Note · Sprawdź wynik przez `ss -tlnp`: usługi wewnętrzne powinny pokazywać `10.88.0.x`, nigdy `0.0.0.0` ani publicznego IP.

Skalowanie: kiedy przejść na narzędzia

Ręcznie napisana siatka sprawdza się, dopóki węzłów jest niewiele, a zmiany są rzadkie. Każdy nowy węzeł oznacza edycję każdej istniejącej konfiguracji, więc praca rośnie kwadratowo. Gdy staje się to uciążliwe, generuj konfiguracje zamiast je pisać.

W NoctisNode wszystkie nowe węzły VPS są wdrażane w FI-1 (Finlandia), każdy z dedykowanym IPv4 i nielimitowanym portem 1 Gbps, a rozliczanie godzinowe plus API dla agentów (z TTL automatycznego usuwania) sprawiają, że dodawanie i usuwanie węzłów testowych jest tanie. Plany zaczynają się od poziomu Wisp; zobacz plany VPS.

FAQ