WireGuard 5G-filial: låt filialen ringa hubben

När filialen ringer hubben behöver hubben aldrig upptäcka en växlande mobiladress. Konfigurera, verifiera och se sedan vad detta inte löser.

Att peka en filial mot en hubb är den enkla halvan av den här designen när filialen sitter bakom en växlande mobiladress och hubben har ett stabilt namn. Då lär sig hubben filialen från autentiserad trafik i stället för från en post du måste hålla uppdaterad. Kontraktet är enkelt: filialen inleder alltid.

Konfigurera det medvetet och verifiera sedan den del som folk antar fungerar. Båda stegen tar minuter, och det är i det andra dessa designer vanligtvis fallerar.

Vilken sida håller den stabila ändpunkten

Filialens konfiguration namnger hubbens ändpunkt och dess publika nyckel. Hubbens konfiguration namnger filialens publika nyckel och dess tillåtna inre prefix, och den kan helt sakna ändpunkt, eftersom identiteten kommer från nyckeln och inte från källadressen i det sista paketet. Den asymmetrin är hela mekanismen, och den tar bort en hel klass av upptäcktsproblem på hubbens sida.

När filialen skickar ett autentiserat paket registrerar hubben källan det kom från och använder den mappningen för svar. Att numrera om mobilförbindelsen kostar då ingenting utöver nästa handskakning, och varje komponent du inte längre behöver är en som inte kan fallera vid ett byte. Den egenskapen är värd att testa vid en planerad ändring och inte vid en incident. Gör det medan någon kan se båda ändarna samtidigt.

Ge filialen en konfiguration som överlever omnumrering

Håll ändpunkten och keepalive på filialen, och håll hubbens peer-post fri från en hårdkodad adress. Keepalive håller den översatta mappningen öppen tillräckligt länge för att hubben ska kunna skicka oombedd trafik efter en inaktiv period.

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

Tjugofem sekunder är det ofta citerade exemplet för att hålla en NAT-mappning levande, inte ett krav för varje peer. Ställ in det efter den mappningstimeout du faktiskt observerar, och kom ihåg att det genererar trafik på en förbindelse med datakvot så länge gränssnittet är uppe.

På hubben måste filialens peer ha tillåtna prefix som täcker allt filialen skickar. Ett saknat prefix uppträder som ett routningsfel i den bortre änden och ger ingen varning på någon av sidorna, därför är det värt att gå igenom det före det första riktiga paketet. Jämför hubbens tillåtna prefix med filialens gränssnittsadresser före den första anslutningen.

Verifiera mappningen och redundansväxlingen

Bekräfta att handskakningen slutförs, att hubben listar filialens nuvarande ändpunkt och att filialens inre adresser nås genom tunneln. Det är baslinjen, och den bör dokumenteras innan någon rör mobilförbindelsen. Två rader utdata räcker. Spara dem i ärendet med tidsstämpeln.

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

Testa sedan det fel designen finns för. Dra ur den primära WAN:en och bekräfta att filialens underliggande väg till hubben nu går ut via det mobila gränssnittet. En tunnel kan inte reparera en bruten fysisk väg, så en yttre väg som fortfarande pekar på en död upplänk ger en handskakningstimeout som ser exakt ut som ett hubbproblem.

Om den yttre vägen är uttryckligen bunden eller policy-routad måste redundansväxlingen omfatta den. Det gapet mellan en design som läses rätt och en som överlever ett avbrott är oftast det enda som saknas.

Vad den här designen inte löser

Ingenting här tillåter en inkommande anslutning till filialen. Om något på huvudkontoret måste ringa den mobila platsen är tunnelriktningen fel för det kravet, och dynamisk DNS uppdaterar bara ett namn. Leverantörens översättning, inkommande policy och klientens uppdatering av ändpunkten står alla i vägen, och en ändrad post kan inte öppna carrier-grade NAT.

Håll filialens prefix skilt från varje annan plats, och begränsa vad dess gateway vidarebefordrar. Den stabila hubbändpunkten förenklar upptäckt och gör ingenting för routningsdesign, adressplanering eller frågan om vilka applikationsvägar som överlever en redundansväxling.

Skriv fyra saker i runbooken: vem som inleder, vilka prefix som är tillåtna, hur lång keepalive är och vad som händer när den primära förbindelsen faller. De raderna är vad en framtida operatör verkligen behöver klockan tre på natten.

Relaterade artiklar