Zwei Mobilfunkstandorte, keine eingehenden Ports: einen Hub bauen, der funktioniert

Wenn keiner der Standorte eingehende IPv4-Verbindungen annimmt, lassen Sie beide zu einem erreichbaren Hub aufbauen. Führen Sie die Schritte für Routing, Weiterleitung und Rückfall in dieser Reihenfolge aus.

Zwei Standorte an Mobilfunk-Uplinks haben in beide Richtungen dasselbe Problem: Keiner kann eine unaufgeforderte IPv4-Verbindung annehmen, also kann keiner den Server in einem direkten Tunnel spielen. Die Architektur, die funktioniert, setzt einen erreichbaren Dritten in die Mitte: Jeder Standort wählt sich nach außen, und die Mitte leitet nur den Verkehr weiter, den Sie freigeben. Diese Mitte kann ein Router sein, den Sie selbst betreiben, oder ein Produkt, das Peers vermittelt, und das ist nicht dasselbe. Die folgenden Schritte sind so geordnet, dass jeder einen Nachweis liefert, bevor der nächste davon abhängt.

Keiner der Standorte ist anwählbar, also müssen beide nach außen wählen

Bestätigen Sie die Einschränkung, bevor Sie darum herum planen. Vergibt der Anbieter der WAN-Schnittstelle eine private Adresse, macht keine Portweiterleitung am eigenen Router des Standorts sie erreichbar, weil die Übersetzung weiter oben geschieht. Eine öffentliche IPv6-Adresse kann am selben Uplink existieren und das Design völlig verändern, deshalb deckt die Prüfung beide Familien ab. Schreiben Sie die Antwort pro Standort auf, denn die beiden haben selten identische Einschränkungen, selbst wenn sie denselben Anbieter teilen.

Der gewöhnliche Mobilfall sieht aus wie eine Adresse aus dem übersetzten Bereich des Anbieters mit einer Standardroute hindurch. Das ist kein Fehler, der repariert werden muss; es ist der Grund, warum der Hub existiert. Sie suchen jede Adresse, die ein Dritter erreichen kann, ohne dass der Standort zuerst gesprochen hat.

Zwei Befehle beantworten die Adressierungsfrage für den Standort, vor dem Sie stehen. Führen Sie sie auf dem Standort-Router aus, nicht auf einem Laptop dahinter:

ip -4 addr show scope global
ip -6 addr show scope global

Wer Peers vermittelt und wer die Pakete trägt

Vermittlung und Transport sind getrennte Aufgaben, die Produkte oft bündeln, ohne die Grenze sichtbar zu machen. Ein Vermittlungsmechanismus hilft zwei Peers, einen Kandidatenpfad zu finden; ein Relay trägt ihre Pakete, wenn kein direkter Pfad existiert. Der Kauf eines Dienstes, der Peers vermittelt, gibt Ihnen keinen Router, und dieser Unterschied entscheidet, ob das Design überhaupt einen Hub braucht.

Traversierung hat ihr eigenes Vokabular, und die Wörter beschreiben Rollen statt Garantien. Die ICE-Spezifikation beschreibt Kandidaten und Konnektivitätsprüfungen, STUN beschreibt einen Weg, etwas über Adressübersetzung zu lernen, und TURN beschreibt weitergeleiteten Transport für Anwendungen, die es umsetzen. Keiner dieser Mechanismen erscheint in einem herkömmlichen Gateway, weil Sie es auf eine Discovery-Adresse gerichtet haben. Prüfen Sie Traversierung als Produkteigenschaft und nehmen Sie Relay an, bis ein Test das Gegenteil zeigt.

Eine Route pro Standort, einem Peer gehörend

Der Hub braucht einen Tunnel pro Standort, ein eigenes LAN-Präfix dahinter und eine Route für jedes Präfix, die dessen Eigentümer nennt. Im Beispiel ist der Hub 10.61.0.1, Standort A ist 10.61.0.11 mit LAN 10.60.10.0/24 und Standort B ist 10.61.0.12 mit LAN 10.60.20.0/24. Jede Route unten zeigt auf den Peer, dem das Präfix gehört, statt auf die Tunnel-Schnittstelle:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

Weiterleitung muss aktiviert sein, sonst bleiben die Pakete am Hub stehen, ohne dass ein Fehler auf die Ursache zeigt. Der letzte Befehl beantwortet die eigentliche Frage, denn er fragt, welchen Pfad ein Paket vom LAN des Standorts A zum LAN des Standorts B nehmen würde, mit der Quelle im Lookup. Behandeln Sie einen Lookup, der die Tunnel-Schnittstelle nennt, als Nachweis und einen, der auf die Standardroute zurückfällt, als fehlende Route statt als Rätsel. Beschränken Sie den Transit dann bewusst, denn ein Hub, der zwischen jedem Peer weiterleitet, macht zwei Standorte zu einem flachen Netz, und die Zugriffsrichtlinie, von der Sie dachten, Sie hätten sie, greift nicht mehr.

Entscheiden Sie auch, wo die Verschlüsselung endet. Wenn der Hub beide Tunnelenden hält, treten der Betreiber dieser Maschine und ihre Arbeitslast dem Vertrauens- und Verfügbarkeitsmodell bei, und ihre Bandbreite wird Teil des Pfads.

Halten Sie jede Zuordnung über den Anbieter am Leben

Jeder Standort baut seinen eigenen Tunnel auf, und jeder muss die Übersetzungszuordnung am Leben halten, sonst vergisst der Anbieter sie. Ein Keepalive auf der aufbauenden Seite bewahrt diese Zuordnung zwischen den Handshakes. Begrenzen Sie die erlaubten Präfixe auf die Hub-Adresse und das entfernte LAN, damit ein kompromittierter Peer kein Präfix beanspruchen kann, das ihm nicht gehört:

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

Spiegeln Sie den Block am anderen Standort mit seinem eigenen entfernten Präfix, und widerstehen Sie dem Drang, den gesamten Tunnelbereich zuzulassen. Ein Handshake, der stoppt und von einem neuen Quellport wieder aufnimmt, ist die Signatur einer abgelaufenen Zuordnung, und die Handshake-Zeitstempel sind der Nachweis, dass es geschah. Ein Intervall kürzer als das Timeout des Anbieters verhindert den Ablauf, statt ihn nachträglich zu reparieren. Wenn der Anbieter sein Übersetzungsverhalten ändert, erwarten Sie, dass sich diese Zeitangaben mit ihm ändern.

Beweisen Sie beide Richtungen, dann die Wiederherstellung

Die Prüfung ist gerichtet, also beweist ein Ping von A nach B die Hälfte des Designs und nichts über den Rückweg. Prüfen Sie den Antwortpfad mit demselben quellbewussten Lookup am Hub, und wiederholen Sie dann den Test von der anderen Seite. Frische Handshakes gehören ebenfalls zum Nachweis, denn ein Tunnel, der eine Stunde untätig war, prüft womöglich eine alte Zuordnung:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

Testen Sie dann den Ausfall, den Sie erwarten, statt den Erfolg, den Sie wollen. Starten Sie den Uplink eines Standorts neu und bestätigen Sie, dass der Tunnel zurückkehrt, ohne dass ein Mensch ein Ende berührt, denn ein Design, das nach jeder Änderung beim Anbieter einen Betreiber braucht, ist unfertig. Halten Sie den primären Pfad, die IPv6-Alternative, wenn es eine gibt, und das Verhalten fest, wenn der Hub nicht verfügbar ist. Der Hub ist nun Teil Ihres Verfügbarkeitsmodells, also schreiben Sie das auf, statt es während eines Ausfalls zu entdecken.

Ähnliche Artikel