WireGuard 5G pobočka: ať pobočka volá rozbočovač sama

Když pobočka volá rozbočovač, rozbočovač nikdy nemusí zjišťovat měnící se mobilní adresu. Nakonfigurujte, ověřte a pak se podívejte, co to neřeší.

Nasměrovat pobočku na rozbočovač je snadná polovina tohoto návrhu, když pobočka sedí za měnící se mobilní adresou a rozbočovač drží stabilní jméno. Rozbočovač se pak pobočku učí z autentizovaného provozu, ne ze záznamu, který musíte udržovat aktuální. Smlouva je jednoduchá: pobočka vždy iniciuje.

Nakonfigurujte to záměrně a pak ověřte tu část, o které lidé předpokládají, že funguje. Oba kroky trvají minuty a právě na druhém tyto návrhy obvykle selhávají.

Která strana drží stabilní koncový bod

Konfigurace pobočky uvádí koncový bod rozbočovače a jeho veřejný klíč. Konfigurace rozbočovače uvádí veřejný klíč pobočky a její povolené vnitřní prefixy a může nést úplně žádný koncový bod, protože identita pochází z klíče, nikoli ze zdrojové adresy posledního paketu. Tato asymetrie je celý mechanismus a odstraňuje celou třídu problémů s objevováním na straně rozbočovače.

Když pobočka pošle autentizovaný paket, rozbočovač zaznamená zdroj, odkud dorazil, a použije toto mapování pro odpovědi. Přečíslování mobilního spoje pak nestojí nic kromě dalšího handshake a každá komponenta, kterou už nepotřebujete, je ta, která během přepnutí nemůže selhat. Tuto vlastnost stojí za to otestovat při plánované změně, ne během incidentu. Udělejte to, dokud někdo může sledovat oba konce současně.

Dejte pobočce konfiguraci, která přežije přečíslování

Držte koncový bod a keepalive na pobočce a záznam protějšku na rozbočovači držte bez natvrdo zapsané adresy. Keepalive drží přeložené mapování otevřené dost dlouho, aby rozbočovač mohl po období nečinnosti poslat nevyžádaný provoz.

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

Dvacet pět sekund je často citovaný příklad pro udržení NAT mapování živého, ne požadavek pro každý protějšek. Nastavte ho podle časového limitu mapování, který skutečně pozorujete, a pamatujte, že generuje provoz na datově omezeném spoji, dokud je rozhraní aktivní.

Na rozbočovači musí povolené prefixy protějšku pobočky pokrývat vše, co pobočka pošle. Chybějící prefix chová se jako selhání směrování na vzdáleném konci a nevyvolá žádné varování na žádné straně, a proto stojí za to ho zkontrolovat před prvním skutečným paketem. Před prvním připojením porovnejte povolené prefixy rozbočovače s adresami rozhraní pobočky.

Ověřte mapování a přepnutí

Potvrďte, že handshake se dokončí, že rozbočovač vypisuje aktuální koncový bod pobočky a že vnitřní adresy pobočky jsou přes tunel dostupné. To je výchozí stav a měl by být zaznamenán, než se někdo dotkne mobilního spoje. Dva řádky výstupu stačí. Uchovejte je v tiketu s časovým razítkem.

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

Potom otestujte poruchu, kvůli které tento návrh existuje. Vytáhněte primární WAN a potvrďte, že podkladová trasa pobočky k rozbočovači nyní vychází přes mobilní rozhraní. Tunel nemůže opravit přerušenou fyzickou cestu, takže vnější trasa, která stále ukazuje na mrtvé vzestupné spojení, vyvolá časový limit handshake, jenž vypadá přesně jako problém rozbočovače.

Pokud je vnější cesta výslovně svázaná nebo směrovaná politikou, přepnutí ji musí zahrnout. Ta mezera mezi návrhem, který se čte správně, a tím, který přežije výpadek, je obvykle jediná chybějící věc.

Co tento návrh neřeší

Nic zde nepřipouští příchozí připojení k pobočce. Pokud něco v ústředí musí vytočit mobilní lokalitu, směr tunelu je pro tento požadavek špatný a dynamický DNS aktualizuje jen jméno. Překlad poskytovatele, příchozí politika i obnovení koncového bodu klientem zůstávají v cestě a změněný záznam nemůže otevřít NAT na úrovni operátora.

Držte prefix pobočky oddělený od každé jiné lokality a omezte, co bude její brána přeposílat. Stabilní koncový bod rozbočovače zjednodušuje objevování a nic nedělá pro návrh směrování, plánování adres ani otázku, které trasy aplikací přežijí přepnutí.

Napište do runbooku čtyři věci: kdo iniciuje, které prefixy jsou povolené, jak dlouhý je keepalive a co se stane, když primární spoj vypadne. Právě tyto řádky budoucí operátor ve tři ráno skutečně potřebuje.

Související články