Utwardzony serwer WireGuard z IPv6, który faktycznie routuje

Co to buduje

Jedna instancja uruchamiająca WireGuard, nadająca każdemu klientowi prywatny adres IPv4, trasowany adres IPv6 z własnego /48 oraz resolver działający wewnątrz tunelu, aby zapytania DNS nigdy nie wybierały innej ścieżki niż reszta ruchu. Zapora domyślnie odrzuca pakiet w obu kierunkach. Przekazywanie jest włączone tylko dla interfejsu tunelu i tylko dla ruchu wychodzącego.

Przetestowane na R-4 w AMS-01 z Debianem 13. WireGuard jest jednowątkowy i działa w jądrze, więc większa liczba rdzeni nie daje nic aż do momentu, gdy przesyłasz wiele gigabitów na sekundę. Znacznie ważniejsza jest lokalizacja: wybierz tę najbliższą Twojemu faktycznemu miejscu, bo każda dodana tutaj milisekunda jest dodawana do każdego pakietu.

Zanim zaczniesz

• Wdrożona instancja i dostęp root przez SSH.
• Dodatek IPv6 /48 włączony w panelu. Dołączone /64 wystarczy dla pojedynczego klienta, ale podsieci dla każdego klienta w obrębie jednego /64 wymaga pośredniczenia w wykrywaniu sąsiadów, co jest hobby, a nie konfiguracją.
• Nazwa hosta wskazująca na instancję. Wszystko poniżej używa vpn.example.com.
• Każdy adres 2001:db8: w tym dokumencie jest przestrzenią dokumentacyjną. Zastąp prefiks tym widocznym na stronie instancji.

1. Pakiety i ustawienia jądra

apt update && apt full-upgrade -y
apt install -y wireguard-tools nftables unbound qrencode
ip -br link

Ta ostatnia komenda wypisuje nazwę Twojego interfejsu zewnętrznego. Na naszych obrazach KVM to ens3; jeśli u Ciebie jest inna, podstaw ją wszędzie poniżej. Teraz jądro:

cat > /etc/sysctl.d/99-wireguard.conf <<EOF
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.ens3.accept_ra = 2
net.ipv4.conf.all.rp_filter = 1
EOF
sysctl --system

Linia z accept_ra = 2 to ta, o której ludzie zapominają. Włączenie przekazywania IPv6 powoduje, że jądro przestaje przyjmować reklamy routera, domyślna trasa znika w ciągu dziesięciu minut, a maszyna gaśnie na v6, nadal odpowiadając na v4. Ustawienie jej na dwa powoduje dalsze przyjmowanie reklam routera na hoście przekazującym.

2. Klucze

install -d -m 700 /etc/wireguard
umask 077
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub
wg genkey | tee /etc/wireguard/laptop.key | wg pubkey > /etc/wireguard/laptop.pub
wg genpsk > /etc/wireguard/laptop.psk

Klucz współdzielony nie jest tu opcjonalny. Nic nie kosztuje, to jedna linia w każdej konfiguracji, i to różnica między tunelem, który jest po prostu bezpieczny dziś, a takim, który pozostaje bezpieczny wobec przeciwnika rejestrującego ruch teraz, aby go odszyfrować później.

3. Interfejs serwera

Zapisz /etc/wireguard/wg0.conf, wklejając zawartość kluczy tam, gdzie zaznaczono:

[Interface]
Address = 10.7.0.1/24, 2001:db8:1a2b:7::1/64
ListenPort = 51820
PrivateKey = <contents of /etc/wireguard/server.key>
MTU = 1420

[Peer]
# laptop
PublicKey = <contents of /etc/wireguard/laptop.pub>
PresharedKey = <contents of /etc/wireguard/laptop.psk>
AllowedIPs = 10.7.0.2/32, 2001:db8:1a2b:7::2/128

Po stronie serwera AllowedIPs to tablica routingu, a nie lista uprawnień. Nadaj każdemu peerowi dokładnie adresy, które posiada, i nic szerszego, w przeciwnym razie dwóch klientów będzie walczyć o tę samą trasę, a przegrany po prostu przestanie otrzymywać pakiety.

chmod 600 /etc/wireguard/wg0.conf

4. Resolver wewnątrz tunelu

Kierowanie klientów do publicznego resolwera niweczy w dużej mierze sens. Unbound jest już zainstalowany; podaj mu /etc/unbound/unbound.conf.d/tunnel.conf:

server:
  interface: 10.7.0.1
  interface: 2001:db8:1a2b:7::1
  access-control: 10.7.0.0/24 allow
  access-control: 2001:db8:1a2b:7::/64 allow
  do-ip6: yes
  prefetch: yes
  hide-identity: yes
  hide-version: yes
  qname-minimisation: yes

Unbound nie uruchomi się, zanim tunel nie istnieje, ponieważ te adresy jeszcze nie są aktywne. Zsekwencjonuj to właściwie, zamiast z tym walczyć:

systemctl edit unbound

[Unit]
[email protected]
[email protected]

5. Zapora sieciowa

Zastąp /etc/nftables.conf w całości:

flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    ct state invalid drop
    iif lo accept
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
    tcp dport 22 accept
    udp dport 51820 accept
    iifname "wg0" udp dport 53 accept
    iifname "wg0" tcp dport 53 accept
  }
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "wg0" oifname "ens3" accept
    iifname "wg0" oifname "wg0" drop
  }
  chain output {
    type filter hook output priority filter; policy accept;
  }
}

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.7.0.0/24 oifname "ens3" masquerade
  }
}

Zwróć uwagę na to, czego nie ma: nie ma tabeli NAT dla IPv6. Klienci wychodzą z własnym adresem z Twojego /48, co jest całym powodem brania /48 na początku. Linia z iifname "wg0" oifname "wg0" drop uniemożliwia peerom wzajemne połączenia, czego chcesz, chyba że celowo budujesz mesh.

systemctl enable --now nftables
nft list ruleset | head -20

6. Uruchomienie

systemctl enable --now wg-quick@wg0
systemctl restart unbound
wg show wg0

7. Klient

[Interface]
PrivateKey = <contents of /etc/wireguard/laptop.key>
Address = 10.7.0.2/24, 2001:db8:1a2b:7::2/64
DNS = 10.7.0.1
MTU = 1420

[Peer]
PublicKey = <contents of /etc/wireguard/server.pub>
PresharedKey = <contents of /etc/wireguard/laptop.psk>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Dla telefonu zamień to w kod QR na serwerze i sfotografuj terminal:

qrencode -t ansiutf8 < /root/laptop.conf

Na kliencie Debian lub Ubuntu linia z DNS = wymaga zainstalowanego openresolv, w przeciwnym razie wg-quick wypisze ostrzeżenie i po cichu pozostawi stary resolver na miejscu. To najczęstsza przyczyna tunelu, który działa doskonale i przecieka przy każdym zapytaniu.

Weryfikacja

Cztery kontrole, w kolejności. Wszystko, co nie działa, mówi Ci, do którego kroku wrócić.

# on the server, after connecting the client
wg show wg0 latest-handshakes
wg show wg0 transfer

Znacznik czasu uzgadniania w ciągu ostatnich dwóch minut i niezerowe liczniki w obu kierunkach oznaczają, że zarówno kryptografia, jak i routing są w porządku.

# on the client
ping -c3 10.7.0.1
ping -c3 2001:db8:1a2b:7::1
dig @10.7.0.1 paragonvps.com AAAA +short

Trzecia komenda dowodzi, że resolver tunelu odpowiada. Jeśli nastąpi przekroczenie limitu czasu, unbound uruchomił się przed utworzeniem wg0; zrestartuj go.

Ostatnia kontrola jest jedyną, która dowodzi, że Twój ruch wychodzi tam, gdzie myślisz, i wymaga drugiej maszyny. Wystarczy dowolna inna instancja we flocie, w dowolnym mieście:

# on the second instance
nc -lv 9101

# on the client, tunnel up
curl -m5 -4 http://second.example.com:9101/
curl -m5 -6 http://second.example.com:9101/

Nasłuchiwacz wypisuje adres źródłowy każdego połączenia. Twoja próba v4 powinna przyjść z serwera WireGuard, ponieważ został zmasqueradowany. Próba v6 powinna przyjść z własnego adresu tunelowego klienta w obrębie Twojego /48, nietknięta, co oznacza trasowanie, a nie pośredniczenie.

Gdy coś idzie nie tak

Stąd sensowne kolejne kroki to drugi punkt końcowy w innym regionie i stack monitorujący, który mówi Ci, kiedy jeden z nich przestaje odpowiadać. Oba są opisane gdzie indziej w poradnikach; strona sieci wyjaśnia, co robi edge z Twoim ruchem, zanim dotrze do Ciebie.