WireGuard 5G-Filiale: Lassen Sie die Filiale den Hub anwählen

Wenn die Filiale den Hub anwählt, muss der Hub nie eine wechselnde Mobilfunkadresse ermitteln. Konfigurieren, prüfen, dann sehen, was das nicht löst.

Eine Filiale auf einen Hub zu richten, ist die leichte Hälfte dieses Entwurfs, wenn die Filiale hinter einer wechselnden Mobilfunkadresse sitzt und der Hub einen stabilen Namen hat. Der Hub lernt die Filiale dann aus authentifiziertem Verkehr, statt aus einem Datensatz, den Sie aktuell halten müssen. Der Vertrag ist einfach: Die Filiale beginnt immer.

Konfigurieren Sie es bewusst und prüfen Sie dann den Teil, von dem die Leute annehmen, dass er funktioniert. Beide Schritte dauern Minuten, und beim zweiten scheitern diese Entwürfe meistens.

Welche Seite hält den stabilen Endpunkt

Die Konfiguration der Filiale nennt den Endpunkt und den öffentlichen Schlüssel des Hubs. Die Konfiguration des Hubs nennt den öffentlichen Schlüssel der Filiale und ihre erlaubten inneren Präfixe, und sie trägt möglicherweise gar keinen Endpunkt, weil die Identität aus dem Schlüssel kommt und nicht aus der Quelladresse des letzten Pakets. Diese Asymmetrie ist der ganze Mechanismus, und sie entfernt eine ganze Klasse von Ermittlungsproblemen auf der Hub-Seite.

Wenn die Filiale ein authentifiziertes Paket sendet, zeichnet der Hub die Quelle auf, von der es kam, und nutzt diese Zuordnung für Antworten. Das Umnummerieren der Mobilfunkstrecke kostet dann nichts außer dem nächsten Handshake, und jede Komponente, die Sie nicht mehr brauchen, ist eine, die beim Umschalten nicht ausfallen kann. Diese Eigenschaft sollte man bei einer geplanten Änderung testen und nicht während eines Vorfalls. Tun Sie es, solange jemand beide Enden gleichzeitig beobachten kann.

Geben Sie der Filiale eine Konfiguration, die das Umnummerieren übersteht

Halten Sie den Endpunkt und die Keepalive auf der Filiale und halten Sie den Peer-Eintrag des Hubs frei von einer fest verdrahteten Adresse. Die Keepalive hält die übersetzte Zuordnung lange genug offen, damit der Hub nach einer Ruhephase unaufgeforderte Pakete senden kann.

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

Fünfundzwanzig Sekunden ist das häufig zitierte Beispiel, um eine NAT-Zuordnung am Leben zu halten, keine Anforderung für jeden Peer. Legen Sie ihn nach dem Zuordnungs-Timeout fest, den Sie tatsächlich beobachten, und bedenken Sie, dass er auf einer datentarifierten Strecke Verkehr erzeugt, solange die Schnittstelle aktiv ist.

Auf dem Hub müssen die erlaubten Präfixe des Filial-Peers alles abdecken, was die Filiale senden wird. Ein fehlendes Präfix verhält sich wie ein Routingfehler am fernen Ende und erzeugt auf keiner Seite eine Warnung, weshalb es sich lohnt, das vor dem ersten echten Paket zu prüfen. Vergleichen Sie die erlaubten Präfixe des Hubs vor der ersten Verbindung mit den Schnittstellenadressen der Filiale.

Prüfen Sie die Zuordnung und das Failover

Bestätigen Sie, dass der Handshake abgeschlossen wird, dass der Hub den aktuellen Endpunkt der Filiale führt und dass die inneren Adressen der Filiale durch den Tunnel erreichbar sind. Das ist die Grundlinie, und sie sollte festgehalten werden, bevor jemand die Mobilfunkstrecke anfasst. Zwei Zeilen Ausgabe genügen. Legen Sie sie mit dem Zeitstempel zum Ticket.

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

Testen Sie dann den Ausfall, für den der Entwurf existiert. Ziehen Sie das primäre WAN ab und bestätigen Sie, dass die zugrunde liegende Route der Filiale zum Hub jetzt über die Mobilfunkschnittstelle geht. Ein Tunnel kann einen gebrochenen physischen Pfad nicht reparieren, daher erzeugt eine äußere Route, die noch auf eine tote Uplink-Verbindung zeigt, einen Handshake-Timeout, der genau wie ein Hub-Problem aussieht.

Ist der äußere Pfad ausdrücklich gebunden oder policy-geroutet, muss das Failover ihn einschließen. Diese Lücke zwischen einem Entwurf, der sich richtig liest, und einem, der einen Ausfall übersteht, ist meist das Einzige, was fehlt.

Was dieser Entwurf nicht löst

Nichts hier lässt eine eingehende Verbindung zur Filiale zu. Muss etwas in der Zentrale die Mobilfunkstelle anwählen, ist die Tunnelrichtung für diese Anforderung falsch, und dynamisches DNS aktualisiert nur einen Namen. Anbieter-Übersetzung, eingehende Richtlinie und die Endpunkt-Aktualisierung durch den Client stehen alle im Weg, und ein geänderter Datensatz kann kein Carrier-Grade-NAT öffnen.

Halten Sie das Präfix der Filiale von jedem anderen Standort getrennt und begrenzen Sie, was ihr Gateway weiterleitet. Der stabile Hub-Endpunkt vereinfacht die Ermittlung und tut nichts für Routing-Entwurf, Adressplanung oder die Frage, welche Anwendungsrouten ein Failover überstehen.

Schreiben Sie vier Dinge ins Runbook: wer beginnt, welche Präfixe erlaubt sind, wie lang die Keepalive ist und was passiert, wenn die primäre Strecke ausfällt. Diese Zeilen sind es, was ein künftiger Betreiber um drei Uhr nachts wirklich braucht.

Ähnliche Artikel