Čtěte konfiguraci WireGuard řádek po řádku, od Interface k Peer

Většina rozbitých konfigurací WireGuard nemá špatnou hodnotu; dávají správnou hodnotu na špatnou stranu. Privátní klíč patří tomuto stroji, peer nese veřejný klíč druhého stroje a adresa sedí v bloku interface, i když popisuje, kde tunel žije. Čtěte soubor jako dva směry, které se setkávají, a pak zkontrolujte, co pomocný skript přidal navrch. Protokol sám má méně polí než soubor a ta navíc stojí za to znát zvlášť.

Klíče interface popisují tento stroj

Blok interface drží vlastní identitu tohoto konce. PrivateKey je ta identita a nikdy neopustí host; odpovídající veřejný klíč se z ní odvozuje a právě ten ostatní peers uvádějí. ListenPort je místo, kde tato strana přijímá handshaky, takže dva klienti za jednou adresou potřebují různé porty.

Address je adresa tunelu, na kterou tento host odpovídá, zapsaná s délkou prefixu, protože bude i zdrojem, který použije. Špatný prefix zde mění, které cíle host považuje za přímo propojené, což dává poruchy, které vypadají jako směrování, ne jako konfigurace.

Vše ostatní v [Interface] bloku s reálným klientem obvykle přidává wg-quick: DNS, MTU, Table a řádky háků. Nejsou to pole protokolu a holé wg nastavení je zcela ignoruje.

Každá položka peer popisuje jednu druhou stranu

Blok [Peer] je vzdálená strana. PublicKey je odvozený klíč této strany, nikdy její privátní klíč, a PresharedKey je volitelné další tajemství, které obě strany musí mít shodné. Endpoint je kam posílat a PersistentKeepalive žádá tento host, aby po intervalu poslal paket, když nic jiného nevychází.

Většinu zmatku zde vysvětlují dvě chyby. Zkopírování vlastního privátního klíče do bloku peer způsobí, že oba konce sdílejí jednu identitu, a handshake selže způsobem, který se špatně loguje. Vynechání Endpoint u klienta je obvykle záměrné, protože server se adresu naučí z příchozího handshaku; vynechání u serveru, který musí iniciovat, záměrné není. Pamatujte také, že keepalive drží mapování NAT otevřené a nezlepšuje propustnost ani nesnižuje latenci, takže třicet sekund paketů navíc nic nekoupí, když provoz už teče.

AllowedIPs je směrování, ne seznam oprávnění

AllowedIPs je kryptoklíčové směrování WireGuardu. Odchozí směr rozhoduje, který peer dostane paket podle cíle. Příchozí směr rozhoduje, zda se paket přicházející od tohoto peeru přijme podle zdroje. Stejné pole dělá obojí, proto to není seznam řízení přístupu ani seznam povolených webů.

Úzký AllowedIPs na serveru pro klienta znamená, že server přijme jen pakety tvrdící tyto zdroje a pošle jen tyto cíle tomuto klientu. Rozšiřte jednu stranu bez druhé a dostanete tunel, který naskočí a nic nepropustí.

Co wg-quick přidává kolem protokolu

wg-quick čte stejný soubor a provádí síťové kroky, které protokol nechává operačnímu systému. Přiřadí adresu rozhraní, přidá trasy odvozené z AllowedIPs, zapíše nastavení resolveru a spustí příkazy háků v pořadí.

Tato vrstva vysvětluje klasickou asymetrii. Soubor s 0.0.0.0/0 a řádkem DNS dá klientovi výchozí trasu a resolver a se serverovými pravidly předávání či NAT neudělá vůbec nic. Ta patří vlastní konfiguraci serveru a žádný klientský soubor je nemůže dodat.

Držte jeden vlastník souboru. Ruční úprava, dokud je SaveConfig zapnutý, znamená, že vaše úprava zmizí při příštím pádu rozhraní a rozhraní vám neřekne, že se to stalo.

Kontrolujte aplikovaný stav, ne soubor

Soubor je záměr. Aplikovaný stav je to, co drží jádro, a rozejdou se vždy, když pomocník, drop-in nebo hák po aktivaci něco upravil.

Čtěte živý stav a adresování společně a pak obojí porovnejte s tím, co jste napsali:

sudo wg show
ip -4 addr show dev wg0
ip -4 route show dev wg0
grep -v "^#" /etc/wireguard/wg0.conf

Pokud je seznam peerů prázdný, rozhraní vzniklo, aniž by byla jeho konfigurace aplikována. Pokud adresy a trasy existují, ale čítače zůstávají na nule, soubor se načetl a handshake selhává, což je problém klíče nebo koncového bodu, ne pořadí sekcí. Porovnejte oba pohledy před úpravou, protože rozdíl mezi nimi je obvykle skutečná závada.