Plný tunel WireGuard: AllowedIPs 0.0.0.0/0 nestačí

Zadat 0.0.0.0/0, ::/0 do AllowedIPs peeru je krok, který si všichni pamatují, a rozhoduje jen o tom, jaký provoz smí peer nést. Tyto prefixy nevytvářejí žádné trasy, nic nepředávají na druhé straně a nechávají resolver každé aplikace přesně tam, kde byl. Čtyři oddělené věci musí platit současně, aby byl plný tunel skutečně plný, a nejlépe se kontrolují v pořadí níže, protože pozdější kontrola nemůže zachránit dřívější. Každá kontrola níže je fakt, který lze přečíst ze stroje, ne nastavení, u kterého doufáte, že bylo použito.

Co prefix peeru vybírá a co ne

AllowedIPs je zároveň selektor i oprávnění. Říká lokální straně, které cíle smějí být posílány tomuto peeru, a přijímající straně říká, které zdrojové adresy smí tento peer předkládat. To je celá práce. Nic v tomto popisu nevytváří trasu na hostiteli, nezapíná předávání na vzdálené straně ani se nedotýká překladu jmen.

Právě proto konfigurace může vypadat úplně a chovat se jako rozdělený tunel. Prefix říká, že peer by přijal všechno; směrovací tabulka hostitele rozhoduje, co tam skutečně dorazí, a brána rozhoduje, zda něco vyjde. Žádné z těch tří rozhodnutí nežije v sekci peeru.

Směrovat klienta, ne jen seznam peerů

Správci jako wg-quick programují směrovací tabulku hostitele za vás, a proto se dva stejné konfigurační soubory chovají různě podle toho, jak rozhraní vzniklo. Minimální profil je dost krátký na přečtení na jeden doušek:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Práci nesou dva detaily. Pole Address je jeden prefix hostitele, ne podsíť, o které si klient myslí, že ji vlastní, a právě správce převádí výchozí AllowedIPs na skutečnou výchozí trasu. Zvedněte stejný soubor pomocí ip link a wg setconf a neobjeví se vůbec žádné trasy, což vypadá jako rozbitý tunel, ale je to zdravý tunel s vynechaným krokem směrování. Manuál wg-quick dokumentuje směrování a Table chování, které tito správci přidávají.

Čtěte výsledek, ne soubor: ip route get 1.1.1.1 má pojmenovat rozhraní tunelu a wg show má hlásit nedávný handshake s počítadlem přenosu, které se hýbe. Handshake bez trasy znamená, že správce nikdy neběžel, a další úprava profilu to nespraví. Spouštějte rozhraní tak, jak ho spustí uživatel, jinak test měří váš shell místo nasazení.

Udržet koncový bod mimo tunel

Plný tunel zachytí každý cíl, včetně toho, se kterým musí mluvit, aby existoval. Správci to řeší přidáním trasy hostitele pro koncový bod přes původní bránu, a proto správná konfigurace téměř vždy obsahuje jednu záměrnou výjimku. Použití poloviny konfigurace správcem a druhé poloviny ručně je obvyklý způsob, jak tato výjimka zmizí.

Pokud je koncovým bodem jméno hostitele, které se překládá na několik adres, nebo na rodinu, kterou nenášíte, výjimka špatně stárne a tunel může selhat po opětovném připojení, které vypadalo rutinně. Přišpendlete koncový bod na adresu, kterou ovládáte, nebo potvrďte, že jej správce přehodnocuje, a po každé změně sítě znovu přečtěte trasu hostitele.

Stejný mechanismus vysvětluje, proč se plný tunel a captive portál hádají. Portál očekává, že zachytí provoz, který váš tunel nyní zachycuje, takže v hotelových a letištních sítích tunel zvedáte po přihlášení do portálu, nikdy před ním.

Předávání a zpětná cesta na bráně

Na bráně zapněte předávání pro rodinu, kterou nesete, povolte forward řetěz v obou směrech, když překládáte, a potvrďte zpětnou cestu vyhledáním specifickým pro zdroj. Nic z toho nevyplývá z úspěšného handshake, protože handshake dokazuje jen to, že si dva peery mohou vyměňovat UDP. Nic to neříká o tom, co se potom stane s dekapsulovaným paketem.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Vyhledání běží na bráně, ne na klientovi, jinak budete číst jinou směrovací tabulku. Pokud pojmenuje špatné rozhraní nebo ohlásí, že žádná trasa není, pak žádná změna na straně klienta nevytvoří výstup do internetu. Když brána překládá adresy klientů na cestě ven, odpověď závisí na tomto stavu překladu, takže pravidlo musí existovat pro oba směry toku, ne jen pro odchozí.

DNS a stav selhání, testované odděleně

Protokol sám nenastavuje resolver žádné aplikace. wg-quick aplikuje řádek DNS přes integraci resolveru distribuce, kontejnery a prohlížeče s vlastními stacky jej mohou ignorovat, a proto jméno může selhat, zatímco tunel nese pakety bezchybně. Testujte jménem hostitele, ne adresou, a poznamenejte, který server odpověděl, místo abyste předpokládali, že to byl ten z profilu.

Rodiny adres jsou samostatný test se samostatnou odpovědí. Výchozí trasa v4 neříká nic o tom, co udělá v6 připojení nějaké aplikace, a tunel, který tiše propouští druhou rodinu, je horší než ten, který hlasitě selhává. Ptejte se na jméno přes každou rodinu, přečtěte rozhraní, které každý požadavek použil, a zkontrolujte počítadla překladu před a po, protože pravidlo, které na nic nepasuje, vypadá stejně jako pravidlo, které chybí.

Nakonec otestujte stav, který chcete, když se tunel zastaví. Plný tunel má selhat zavřeně pro provoz, který tvrdí: pokud rozhraní spadne a aplikace tiše pokračují přes fyzické spojení, je návrh rozdělený tunel s kroky navíc. Zapište zamýšlené chování při selhání, záměrně ho zkontrolujte a skončete zapsáním čtyř odpovědí — který správce zvedá rozhraní, která trasa nese výchozí, kdo předává a překládá na bráně a který resolver odpovídá.