Routenbasiertes VPN zwischen Linux StrongSwan und Cisco ISR / Sudo Null IT News

Schönen Tag!

Ich wollte die Implementierung von Hun-and-Spoke VPN zwischen Cisco ISR (als Spocks) und Linux + StrongSwan (als Hubs) teilen.

Eine kleine Hintergrundgeschichte.

Derzeit nutzt unsere Infrastruktur eine Mono-Vendor-Umgebung auf Basis von Cisco-Lösungen. Angesichts der jüngsten Ereignisse begannen sie, nach möglichen Ersatzoptionen sowohl auf der Brunch-Seite (Spocks) als auch auf der Hub-Seite zu suchen.

Hubs befinden sich im DC in Form von Cisco CSR. Und bei ihnen lag das Hauptproblem, da heimische Lösungen noch nicht so etwas wie einen komplett fertigen virtuellen Router bieten können (korrigieren Sie in den Kommentaren, wenn ich falsch liege).
Aus diesem Grund haben wir uns vorerst für die Linux+StrongSwan+FRR-Lösung entschieden.

Und die erste Aufgabe, die es zu lösen galt, war die Übertragung der aktuellen Spock-Infrastruktur auf einen neuen virtuellen Router im Sinne des Baus von Tunneln.

Alle unsere Tunnel werden über das Internet gebaut.

Auf der CSR-Seite wird eine virtuelle Vorlage mit IKEv2 + IPSec-Verschlüsselung verwendet, und auch unter Verwendung von IKEv2 schieben wir IP in Richtung Spocks. Dementsprechend wollte ich dieses Schema beibehalten.

Um ähnliche Funktionen unter Linux zu reproduzieren, verwenden wir StrongSwan und das Dienstprogramm swanctl, da StrongSwan selbst ipsec.conf als veraltete Methode betrachtet. Wir werden ein routenbasiertes VPN basierend auf XFRM-Schnittstellen erstellen.

Wir benötigen gemäß den Empfehlungen von StrongSwan:

  1. StrongSwan-Version ist mindestens 5.8.0;

  2. Linux-Kernel ab 4.19;

  3. iproute2-Versionen ab 5.1.0+

Bei mir:

  1. Strongswan – 5.9.6;

  2. Linux-Kernel – 5.4.17;

  3. IProute2 – 5.12.0;

Wir gehen davon aus, dass Sie bereits die Ports 500,4500 udp offen haben und das ESP-Protokoll (50) erlaubt ist

Füllen Sie die swanctl.conf-Konfiguration aus:

swanctl.confconnections { dmvpn { include /etc/strongswan/swanctl/conf.d/ike_sa_default.conf # Sie können Konfigurationselemente einschließen pools = dmvpn # Pool zum “Pushen” von Adressen an entfernte Hosts keyingtries = 1 # Anzahl der Versuche, a Verbindung bei Erstverbindung mobike = no # Mobike ausschalten um !möglich! Probleme. Unsere Clients sind statische Version = 2 # IKE-Version remote_addrs = %any # Verbindung von jeder Adresse zulassen remote-all { # Authentifizierungsmethode der entfernten Seite angeben auth = psk } local_addrs = 198.51.100.1 # Geben Sie unsere öffentliche Adresse für diese Verbindung local-dmvpn an { # Geben Sie die Authentifizierungsmethode unserer Seite an auth = psk } Proposals = aes256-sha512-modp2048, default # Vorschlag für den Aufbau eines IKE-Tunnels dpd_delay = 10s # Regelmäßige Überprüfung, ob der Peer “live” ist children { dmvpn { include /etc/ strongswan/swanctl/ conf.d/child_sa_default.conf # Sie können Konfigurationselemente einbinden updown = /etc/strongswan/swanctl/scripts/auto-interface-xfrm # Geben Sie das Verzeichnis an, in dem sich das Skript befindet, das auf der CHILD_SA ausgeführt wird event up and down start_action = start # Verbindung sofort aktivieren esp_proposals = aes256-sha512, default # Vorschlag zum Aufbau von ipsec local_ts = 0.0.0.0/0 # Angabe von Traffic-Selektoren zum Aufbau eines routenbasierten VPN. remote_ts = 0.0.0.0/0 # Datenverkehrsselektoren zum Aufbau eines routenbasierten VPN angeben. if_id_out = %unique # Um Schnittstellen mit eindeutigen xfrm-Richtlinien zu erstellen if_id_in = %unique # Um Schnittstellen mit eindeutigen xfrm-Richtlinien zu erstellen dpd_action = clear # Was zu tun ist, wenn DPD ausgelöst wird. Schließen Sie in diesem Fall die Verbindung } } } } pools { # Pools erstellen dmvpn { addrs = 192.0.2.2-192.0.2.255 } } authorities { } secrets { # Authentifizierungstypen erstellen ike-dmvpn { secret = “VERY-STRONG-PSK ” } }

Damit Schnittstellen automatisch erstellt und gelöscht werden und ihnen eindeutige IPSec-Richtlinienkennungen zugewiesen werden, verwenden wir die integrierte swanctl-Funktionalität – updown. Es wird beim Aufwärts- oder Abwärtsereignis CHILD_SA ausgelöst. Das Skript wird automatisch aufgerufen. Wir legen es zum Beispiel in ein Verzeichnis, /etc/strongswan/swanctl/scripts/auto-interface-xfrm und ausführbar machen.

Das Skript selbst:

auto-interface-xfrm#!/bin/bash # set charon.install_virtual_ip = no um zu verhindern, dass der Daemon auch den VIP installiert set -o nounset set -o errexit VTI_IF=”Virtual-Access${PLUTO_IF_ID_OUT}” # Besser id verwenden xfrm-Schnittstelle, damit eindeutige Bezeichner nicht wegfliegen. Und der Daemon hat die Kontrolle über Schnittstellen nicht verloren case “${PLUTO_VERB}” in up-client) ip link add “${VTI_IF}” type xfrm dev uplink-1 \ if_id “${PLUTO_IF_ID_OUT%%/*}” ip addr add 192.0 .2.1/32 dev “${VTI_IF}” ip link set “${VTI_IF}” up ip route add “${PLUTO_PEER_SOURCEIP}” dev “${VTI_IF}” # Setzt die Route zum Client sysctl -w “net.ipv4. conf.${VTI_IF}.disable_policy=1” # Wie von strongswan empfohlen, um doppelte Richtliniensuchen zu vermeiden ;; Down-Client) IP-Link del “${VTI_IF}” ;; esac

Von der Cisco isr-Seite ist alles Standard:

Cisco ISRcrypto ikev2-Vorschlag IKE2-PROPOSAL Verschlüsselung aes-cbc-256 Integrität sha512 Gruppe 14 Krypto ikev2-Richtlinie IKE2-POLICY-Vorschlag IKE2-PROPOSAL Krypto ikev2-Schlüsselbund FLEX-KEYIRING-FRR Peer HUB-FRR-01 Adresse 198.51.100.1 Pre-Shared-Key VERY-STRONG-PSK Krypto Ikev2-Profil FLEX-PROFILE-FRR Übereinstimmungsidentität Remote-Adresse 198.51.100.1 255.255.255.255 Authentifizierung Remote-Pre-Share-Authentifizierung Lokaler Pre-Share-Schlüsselbund Lokal FLEX-KEYIRING-FRR dpd 10 3 On-Demand-Krypto-IPsec-Transformation- set TSET-FRR esp-aes 256 esp-sha512-hmac Modus tunnel crypto ipsec Profil FLEX-IPSEC-FRR set transform-set TSET-FRR set ikev2-Profil FLEX-PROFILE-FRR Schnittstelle Tunnel32 Beschreibung HUB-FRR-01-TEST ip Adresse ausgehandelt ip mtu 1300 ip tcp adjust-mss 1260 tunnel source GigabitEthernet0/0/0 tunnel mode ipsec ipv4 tunnel destination 198.51.100.1 tunnel protection ipsec profile FLEX-IPSEC-FRR ip route 192.0.2.1 255.255.255.255 Tunnel32

Die Installation von IKE- und IPSec-Tunneln kann mit dem Befehl swanctl -l überprüft werden

Mit dem Befehl ip xfrm policy können Sie überprüfen, welche Richtlinien an welche Schnittstellenkennungen gebunden sind

IP xfrm-RichtlinieIP xfrm-Richtlinie

Der Befehl ip -d link hilft Ihnen, die xfrm-Richtlinie zu überprüfen und der Schnittstelle zuzuordnen

ip-d-Linkip-d-Link

Jetzt werden Tunnel auf dem Hub nach der Installation von IPSec automatisch erstellt und gelöscht. Alles, was bleibt, ist, FRR zu erhöhen, dynamische BGP-Nachbarn zu konfigurieren, und wir haben einige der Routineoperationen entschieden.

Bereit, Ihre Vorschläge, Kommentare, Erfahrungen und konstruktive Kritik zu hören.

Und vielleicht ist diese kleine Anleitung für jemanden nützlich.

Verknüpfungen

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *