Filial-VPN über 4G: Identität stabil halten, wenn sich die IP ändert

Beginnen Sie bei der Filiale selbst, auf der WAN-Statusseite des 4G-Routers. Liegt die Adresse, die Sie sehen, im privaten Bereich des Anbieters statt in einem öffentlichen, wird keine Portweiterleitung auf dieser Box jemals zulassen, dass der Hub eingehend anruft, und der Tunnel muss von der Filiale nach außen aufgebaut werden. Diese eine Beobachtung entscheidet das Design. Der Rest der Arbeit besteht darin, sicherzustellen, dass der Hub die Filiale an etwas Besserem erkennt als an einer Adresse, die sich alle paar Stunden ändert.

Wo der Tunnel beginnen muss

Prüfen Sie die Adresse gegen den gemeinsam genutzten Adressraum, den Anbieter für ihr eigenes NAT verwenden, 100.64.0.0/10, und gegen die üblichen privaten Bereiche. Einen davon auf einer mobilen Uplink-Verbindung zu sehen, bedeutet in der Regel, dass Carrier-Grade-NAT zwischen der Filiale und dem Internet sitzt und eingehende Verbindungen zu keinem Preis verfügbar sind, den die Filiale zahlen kann. Ist die WAN-Adresse öffentlich, ändert sich aber, haben Sie ein anderes, einfacheres Problem.

Dynamisches DNS hilft nur im zweiten Fall. Es gibt einer wechselnden öffentlichen Adresse einen stabilen Namen zum Anwählen und kann keine Zuordnung erzeugen, die der Anbieter nie bereitgestellt hat. Für den öffentlichen Fall lohnt es sich trotzdem, weil es den einen manuellen Schritt bei einer Umnummerierung entfernt. Was es nicht werden darf, ist die Antwort für eine Filiale, die der Anbieter nie erreichbar gemacht hat.

Trennen Sie die Adresse, die Sie anwählen, von der Identität, die Sie abgleichen

Der Hub braucht etwas Stabiles, worunter er gefunden wird, eine genehmigte feste Adresse oder einen gepflegten Hostnamen. Die Filiale braucht eine stabile Art, erkannt zu werden, und in IKEv2 ist das die Identitätsnutzlast, die sie bei der Authentifizierung vorzeigt, unabhängig von der Quelladresse, die ihre Pakete zufällig tragen. Eine Zeichenkette wie @branch-a.vpn.example funktioniert als diese Identität, selbst während sich die mobile Adresse stündlich ändert.

Diese Zeichenkette wird gegen die Richtlinie abgeglichen, nicht per DNS aufgelöst, also erwarten Sie keine Namensauflösung beim Tunnelaufbau. Die Konfiguration des Hubs muss die erwartete Identität ausdrücklich benennen, und bei Zertifikatsauthentifizierung muss die Identität auch zu dem passen, was das Zertifikat tatsächlich behauptet.

Jede Identität zu akzeptieren, weil die Quelladresse plausibel aussieht, ist der Fehlermodus, den es zu vermeiden gilt. Auf einem Responder bedeutet das, jeden Peer zu akzeptieren, mit einem Identitäts-Platzhalter und einem gemeinsamen Geheimnis, was eine Zeichenkette statt eines Geräts authentifiziert.

Schreiben Sie die Hub-Seite als benannten Peer

In strongSwan-Begriffen ist die Responder-Seite eine Verbindung mit right=%any, die einen Peer von jeder Quelladresse akzeptiert, plus [email protected], das festnagelt, als was sich dieser Peer ausgeben muss. Fügen Sie rightsubnet=10.20.0.0/16 für die LANs der Filiale hinzu, auto=add, damit die Verbindung geladen wird, ohne angewählt zu werden, dpd_delay=30s für Lebendigkeit und mobike=yes, damit ein Adresswechsel absorbiert statt als neuer Peer behandelt wird.

Andere Hersteller drücken dieselben Objekte unter anderen Namen aus, meist einen dynamischen Peer- oder Filialtyp mit einem Identitätsfeld und einem Feld für das geschützte Subnetz. Füllen Sie beides aus; ein allgemeines Dynamisch-Kästchen ist kein Kompatibilitätsplan.

Halten Sie die Filiale als Initiator

Auf der Filiale gilt das Spiegelbild: left=%defaultroute, damit die lokale mobile Adresse so verwendet wird, wie sie gerade ist, [email protected] zum Vorzeigen der Identität, right=hub.example.com für den stabilen Hub-Namen und auto=start, damit der Tunnel ohne einen Menschen hochkommt. Wenn die Mobilstrecke sich wieder verbindet, initiiert die Filiale erneut und der Hub gleicht dieselbe Identität gegen dasselbe Richtlinienobjekt ab.

Erlauben Sie IKE auf UDP 500, NAT-Traversal auf UDP 4500 und das eingekapselte ESP, das folgt, auf beiden Seiten. Lassen Sie sie dann erlaubt: Eine Regel, die sich nur während der Geschäftszeiten öffnet, wird wie ein intermittierender Tunnel aussehen.

Testen Sie den Adresswechsel, nicht nur den ersten Handshake

Bringen Sie den Tunnel hoch, bestätigen Sie ihn, und zwingen Sie die Filiale dann für eine Minute auf eine neue Adresse, indem Sie mobile Daten oder Flugmodus umschalten. Beobachten Sie die Sicherheitsassoziationen am Hub und prüfen Sie, dass sich die Peer-Adresse geändert hat, während die Identität es nicht tat. Ein Tunnel, der nur bis zur ersten Neuzuweisung durch den Anbieter funktioniert, ist überhaupt nicht getestet.

Prüfen Sie dann die geschützten Subnetze getrennt. Eine bestehende SA besagt, dass die Peers sich authentifiziert haben; sie besagt nicht, dass der Hub eine Route zum LAN der Filiale hat oder dass die Filiale Verkehr von der Hub-Seite akzeptiert. Lesen Sie die Routingtabelle und die Firewall-Richtlinie getrennt und senden Sie dann einen Ping von einem Host statt vom Gateway, denn das Gateway ist das am wenigsten repräsentative Gerät in jedem Netz.

Eine stabile Identität macht die Filiale zu einem Richtlinienobjekt, das der Hub benennen kann. Sie macht eine Carrier-NAT-Adresse nicht erreichbar und gewährt dem Rest der Organisation nicht von sich aus Zugriff auf die Filiale.