WireGuard 5G-afdeling: lad afdelingen ringe til hubben

At pege en afdeling mod en hub er den nemme halvdel af dette design, når afdelingen sidder bag en skiftende mobiladresse, og hubben har et stabilt navn. Så lærer hubben afdelingen at kende ud fra autentificeret trafik i stedet for fra en post, du skal holde opdateret. Kontrakten er enkel: afdelingen starter altid.

Konfigurér det bevidst, og verificér derefter den del, som folk antager virker. Begge trin tager minutter, og det er i det andet, disse designs normalt fejler.

Hvilken side har det stabile endepunkt

Afdelingens konfiguration angiver hubbens endepunkt og offentlige nøgle. Hubbens konfiguration angiver afdelingens offentlige nøgle og dens tilladte indre præfikser, og den behøver slet ikke have noget endepunkt, fordi identiteten kommer fra nøglen og ikke fra kilden til den sidste pakke. Den asymmetri er hele mekanismen, og den fjerner en hel klasse af opdagelsesproblemer på hubbens side.

Når afdelingen sender en autentificeret pakke, registrerer hubben den kilde, den kom fra, og bruger den mapping til svar. At omnummerere mobilforbindelsen koster så intet ud over det næste håndtryk, og hver komponent, du ikke længere har brug for, er en, der ikke kan fejle under en omlægning. Den egenskab er værd at teste under en planlagt ændring i stedet for under en hændelse. Gør det, mens nogen kan holde øje med begge ender på én gang.

Giv afdelingen en konfiguration, der overlever omnummerering

Hold endepunktet og keepalive på afdelingen, og hold hubbens peer-post fri for en hårdt kodet adresse. Keepalive holder den oversatte mapping åben længe nok til, at hubben kan sende uopfordret trafik efter en inaktiv periode.

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

Femogtyve sekunder er det ofte citerede eksempel på at holde en NAT-mapping levende, ikke et krav for hver peer. Sæt det ud fra den mapping-timeout, du faktisk ser, og husk, at det genererer trafik på en forbindelse med datagrænse, så længe interfacet er oppe.

På hubben skal afdelingens peer have tilladte præfikser, der dækker alt, hvad afdelingen sender. Et manglende præfiks opfører sig som en routingfejl i den fjerne ende og giver ingen advarsel på nogen af siderne, og derfor er det værd at gennemgå, før den første rigtige pakke. Sammenlign hubbens tilladte præfikser med afdelingens interfaceadresser før den første forbindelse.

Verificér mappingen og failover

Bekræft, at håndtrykket fuldføres, at hubben viser afdelingens nuværende endepunkt, og at afdelingens indre adresser kan nås gennem tunnelen. Det er basislinjen, og den bør registreres, før nogen rører mobilforbindelsen. To linjer output er nok. Gem dem i billetten sammen med tidsstemplet.

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

Test derefter den fejl, som designet findes for. Træk det primære WAN ud, og bekræft, at afdelingens underliggende rute til hubben nu går gennem det mobile interface. En tunnel kan ikke reparere en brudt fysisk vej, så en ydre rute, der stadig peger på et dødt uplink, giver en håndtryk-timeout, som ser præcis ud som et hub-problem.

Hvis den ydre vej er eksplicit bundet eller policy-routet, skal failover omfatte den. Det gab mellem et design, der læses korrekt, og et, der overlever et udfald, er normalt det eneste, der mangler.

Hvad dette design ikke løser

Intet her tillader en indgående forbindelse til afdelingen. Hvis noget på hovedkontoret skal ringe til den mobile lokalitet, er tunnelretningen forkert til det krav, og dynamisk DNS opdaterer kun et navn. Udbyderens oversættelse, indgående politik og klientens opdatering af endepunktet står alle i vejen, og en ændret post kan ikke åbne carrier-grade NAT.

Hold afdelingens præfiks adskilt fra alle andre lokaliteter, og begræns, hvad dens gateway videresender. Det stabile hub-endepunkt forenkler opdagelse og gør intet for routingdesign, adresseplanlægning eller spørgsmålet om, hvilke applikationsruter der overlever en failover.

Skriv fire ting i runbooken: hvem der starter, hvilke præfikser der er tilladte, hvor lang keepalive er, og hvad der sker, når det primære link falder. De linjer er, hvad en fremtidig operatør faktisk har brug for klokken tre om natten.