
Lage
Ich muss eine VPN-Verbindung zwischen zwei Standorten im Netzwerk herstellen. Im Serverraum gab es anscheinend Sicherheitsgateways C-Terra Gateway Version 4.2. Das Schema ist einfach. Der Anbieter hat sogar ein empfohlenes Konfigurationsskript veröffentlicht. Aber ... das Herstellerskript verwendet drei Netzwerkschnittstellen, und meine Gateways haben nur zwei.
Ich koche Kaffee, erinnere mich an meine CCNA und versuche, meine freien Ports in verwalteten Switches zu verwenden.
Mein Netzwerk
Mein Netzwerk besteht aus zwei geografisch getrennten Standorten in einer Broadcast-Domäne. Adressraum: 10.10.205.0/24:

In den Händen von zwei Sicherheitsgateways C-Terra Gateway Version 4.2 mit dem C-Terra L2-Paket.
Informationen zum C-Terra L2-
Paket Mit diesem Paket können Sie eine oder mehrere Gateway-Schnittstellen in den PROMISC-Modus schalten. Die PROMISC-Schnittstelle fängt Datenverbindungsrahmen ab und C-Terra L2 kapselt sie in UDP.
Dann werden UDP-Pakete verschlüsselt (in ESP gekapselt). Dadurch wird eine L2-über-L3-VPN-Verbindung hergestellt. C-Terra L2 ist auf allen Sicherheitsgateways vorinstalliert und wird mit einer separaten Lizenz aktiviert.
Im empfohlenen Szenario befinden sich die Sicherheitsgateways am Rand des Netzwerks, und eine separate Schnittstelle wird für die Verwaltung zugewiesen:

Um die Beschreibung der Schnittstellen zu vereinfachen:
- Gi0 / 0 - PROMISC-Schnittstellen;
- Gi0 / 1 - L3 WAN-Schnittstellen;
- Gi0 / 2 - dedizierte Verwaltungsschnittstellen. Ich verstehe, dass ich das zweite Sicherheitsgateway über den VPN-Tunnel verwalten muss.
Entscheidung
Die erste Tasse Kaffee endete, als ich über 802.1Q auf Habré las - ich erinnerte mich an CCNA. Der zweite Becher hat sich beim Umschalten des Geräts abgekühlt (ich werde ihn in der Mikrowelle erhitzen), wie in der Abbildung gezeigt:

Ich unterscheide drei Arten von Verkehr:
- Hauptverkehr zwischen R1- und R2-Geräten. Ich werde es als BULK DATA bezeichnen und in VLAN 205 einfügen. BULK DATA muss vor der Übertragung zwischen Standorten verschlüsselt werden.
- Gateway-Verwaltungsverkehr - MGMT. Ich werde es zu VLAN 10 bringen. Der MGMT-Verkehr zum Gateway am Remote-Standort muss verschlüsselt sein.
- BULK DATA und MGMT nach der Verschlüsselung werde ich als ESP DATA bezeichnen und in VLAN 100 einfügen.
Nach meinen Schätzungen sieht die BULK DATA / ESP DATA-Übertragung im Netzwerk folgendermaßen aus (grüne Linien stehen für unverschlüsselten Verkehr, rot verschlüsselt):

MGMT-Übertragung für die Gateway-Steuerung am lokalen Standort:

MGMT / ESP DATA-Übertragung für die Gateway-Steuerung am Remote-Standort:

5 Schritte der Einrichtung
Schritt 1. Umgang mit BULK DATA
Ich wähle ein separates VLAN 205 für BULK DATA aus. Dazu stelle ich die Gi0 / 2-Schnittstelle von SW1- und SW2-Geräten auf den Zugriffsmodus mit VLAN 205 ein:
sw1(config)#
interface gi0/2
description BULK_TO_R1
switchport access vlan 205
no shutdown
sw2(config)#
interface gi0/2
description BULK_TO_R2
switchport access vlan 205
no shutdown
Ich mache Schnittstellen Gi0 / 0 von Gateways GW1 und GW2 PROMISC-Schnittstellen. Um BULK DATA an die PROMISC-Schnittstelle zu übergeben, konfiguriere ich den Trunk an die PROMISC-Schnittstelle:
sw1(config)#
interface gi0/0
description LINK_TO_PROMISC_GW1
switchport mode trunk
switchport trunk allowed vlan 205
switchport trunk encapsulation dot1q
no shutdown
sw2(config)#
interface gi0/0
description LINK_TO_PROMISC_GW2
switchport mode trunk
switchport trunk allowed vlan 205
switchport trunk encapsulation dot1q
no shutdown

Schritt 2. Umgang mit lokalem MGMT
Gemäß Plan MGMT-Verkehr mit VLAN 10. Adressraum für VLAN 10: 10.76.76.128/28.
Auf dem SW1- und SW2-Gerät erstelle ich virtuelle vlan10-Schnittstellen:
sw1(config)#
interface vlan10
ip address 10.76.76.129 255.255.255.240
no shutdown
sw2(config)#
interface vlan10
ip address 10.76.76.142 255.255.255.240
no shutdown
Ich mache VLAN 10 natives VLAN, um keine 802.1Q-Schnittstellen auf dem Gateway zu konfigurieren:
sw1(config)#
interface gi0/1
description LINK_TO_WAN_GW1
switchport mode trunk
switchport trunk allowed vlan 10
switchport trunk native vlan 10
switchport trunk encapsulation dot1q
no shutdown
sw2(config)#
interface gi0/1
description LINK_TO_WAN_GW2
switchport mode trunk
switchport trunk allowed vlan 10
switchport trunk native vlan 10
switchport trunk encapsulation dot1q
no shutdown

Ich konfiguriere die Gi0 / 1-Schnittstellen der Sicherheitsgateways:
GW1(config)#
interface gi0/1
ip address 10.76.76.137 255.255.255.240
no shutdown
GW2(config)#
interface gi0/1
ip address 10.76.76.138 255.255.255.240
no shutdown
Jetzt ist GW1 über SSH vom SW1-Gerät aus erreichbar:
sw1#ssh –l root 10.76.76.137
Password:
S-Terra Gate 4.2.18201 (amd64)
root@GW1~#
Ebenso ist GW2 über SSH vom SW2-Gerät aus erreichbar:
sw2#ssh –l root 10.76.76.138
Password:
S-Terra Gate 4.2.18201 (amd64)
root@GW2~#
Schön, noch eine Tasse Kaffee eingegossen.
Schritt 3. Umgang mit MGMT zum Gateway am Remote-Standort Der
MGMT-Verkehr zum Gateway am Remote-Standort muss verschlüsselt sein. Dazu werde ich VLAN 10 über VPN werfen. Der gesamte von der PROMISC-Schnittstelle abgefangene Datenverkehr wird in den VPN-Tunnel eingegeben. Ich werde dem Trunk der PROMISC-Schnittstelle VLAN 10 hinzufügen:
sw1(config)#
interface gi0/0
description LINK_TO_PROMISC_GW1
switchport trunk allowed vlan 10, 205
sw2(config)#
interface gi0/0
description LINK_TO_PROMISC_GW1
switchport trunk allowed vlan 10, 205
Verschwenden Sie keine halbe Stunde mit der Fehlersuche!
Die PROMISC-Schnittstelle sollte keine ESP-DATEN erhalten. Daher ist es wichtig, VLAN 100 in den folgenden Optionen von den Amtsleitungen LINK_TO_PROMISC_GW1 und LINK_TO_PROMISC_GW2 auszuschließen:
switchport trunk allowed vlan 1-99,101-4096
Schritt 4. Ich
komme zu ESP DATA Ich wähle ESP DATA in VLAN 100 auf den Gateways GW1 und GW2 aus.
Adressraum für VLAN 100: 192.168.10.0/30 Dazu erstelle ich auf der WAN-Schnittstelle Gi0 / 1 der Gateways GW1 und GW2 eine 802.1Q-Schnittstelle Gi0 / 1.100.
Ausgehender Verkehr von einer solchen Schnittstelle gehört zu VLAN 100:
GW1(config)#
interface gi0/1.100
ip address 192.168.10.1 255.255.255.252
no shutdown
GW2(config)#
interface gi0/1.100
ip address 192.168.10.2 255.255.255.252
no shutdown

Ich erlaube den Durchgang von VLAN 100 zum Trunk LINK_TO_WAN_GW1 und LINK_TO_WAN_GW2:
sw1(config)#
interface gi0/1
description LINK_TO_WAN_GW1
switchport trunk allowed vlan 10,100
sw2(config)#
interface gi0/1
description LINK_TO_WAN_GW2
switchport trunk allowed vlan 10,100
Die Verbindung zwischen den Geräten SW1 und SW2 muss auch getaggten VLAN 100-Verkehr übertragen:
sw1(config)#
interface gi0/3
description LINK_TO_SW2
switchport mode trunk
switchport trunk allowed vlan 100
switchport trunk encapsulation dot1q
no shutdown
sw2(config)#
interface gi0/3
description LINK_TO_SW1
switchport mode trunk
switchport trunk allowed vlan 100
switchport trunk encapsulation dot1q
no shutdown
Schritt 5. Konfigurieren von C-Terra L2 und IPsec VPN mit GOST
C-Terra L2 wird im Betriebssystem mithilfe der Konfigurationsdatei /opt/VPNagent/etc/l2.conf konfiguriert. Für GW1:
vif tap0
bridge br0
capture eth0
remote 192.168.10.2
mssfix 1400
passtos
Dabei gilt
Folgendes : Erfassung von eth0 - Auswahl der PROMISC-Schnittstelle, Remote 192.168.10.2 - IP-Adresse des IPSec-Peers (Gi0 / 1.100-Schnittstelle des GW2-Gateways).
Für GW2:
vif tap0
bridge br0
capture eth0
remote 192.168.10.1
mssfix 1400
passtos
IKE / IPsec-Parameter konfigurieren. Für GW1:
Gateways verwenden Hostnamen als Bezeichner, legen einen vordefinierten Schlüssel für die Authentifizierung fest (die Nutzungsregeln für die Authentifizierung müssen digitale Zertifikate verwenden, ich werde sie später ändern):
GW1(config)#
crypto isakmp identity hostname
ip host GW2 192.168.10.2
crypto isakmp key KEY hostname GW2
Konfigurieren der DPD-Parameter (Dead Peer Detection):
GW1(config)#
crypto isakmp keepalive 10 2
crypto isakmp keepalive retry-count 5
Ich habe die IPSec-Phase-I-Parameter eingestellt:
GW1(config)#
crypto isakmp policy 1
encr gost
hash gost3411-256-tc26
auth pre-share
group vko2
Ich habe die Parameter für IPSec Phase II eingestellt:
GW1(config)#
crypto ipsec transform-set TSET esp-gost28147-4m-imit
mode tunnel
Da von der PROMISC L2-Schnittstelle abgefangene Frames in UDP gekapselt sind, wird in der Zugriffsliste der Datenverkehr für die Verschlüsselung definiert:
GW1(config)#
ip access-list extended LIST
permit udp host 192.168.10.1 host 192.168.10.2
Ich erstelle eine Kryptokarte und binde sie an Gi0 / 1.100:
GW1(config)#
crypto map CMAP 1 ipsec-isakmp
match address LIST
set transform-set TSET
set peer 192.168.10.2
interface gi0/1.100
crypto map CMAP
Ich gebe die Standardroute durch die IP-Adresse des IPSec-Peers an:
GW1(config)#
ip route 0.0.0.0 0.0.0.0 192.168.10.2
GW2-Gateway-Konfiguration:
GW2(config)#
crypto isakmp identity hostname
ip host GW1 192.168.10.1
crypto isakmp key KEY hostname GW1
crypto isakmp keepalive 10 2
crypto isakmp keepalive retry-count 5
crypto isakmp policy 1
encr gost
hash gost3411-256-tc26
auth pre-share
group vko2
crypto ipsec transform-set TSET esp-gost28147-4m-imit
mode tunnel
ip access-list extended LIST
permit udp host 192.168.10.2 host 192.168.10.1
crypto map CMAP 1 ipsec-isakmp
match address LIST
set transform-set TSET
set peer 192.168.10.1
interface gi0/1.100
crypto map CMAP
ip route 0.0.0.0 0.0.0.0 192.168.10.1
Passierte?
Von Gerät R1 aus pinge ich zu R2:
R1#ping 10.10.205.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.205.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms</code>
R2 ICMP. ? ARP R1 R2:
<source>R1#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.205.1 - aabb.cc00.5020 ARPA GigabitEthernet0/2
Internet 10.10.205.2 54 aabb.cc00.6020 ARPA GigabitEthernet0/2
R2#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.205.1 52 aabb.cc00.5020 ARPA GigabitEthernet0/2
Internet 10.10.205.2 - aabb.cc00.6020 ARPA GigabitEthernet0/2
R1- und R2-Geräte gehen davon aus, dass sie sich im selben Broadcast-Subnetz befinden.
SW1- und SW2-Geräte berücksichtigen, dass sie über zwei Verbindungen miteinander verbunden sind:
sw1#show cdp neighbors
Device ID Local Intrfce Holdtme Capability Platform Port ID
sw2 Gi0/0 146 R S I Linux Uni Gi0/0
sw2 Gi0/3 146 R S I Linux Uni Gi0/3
R1 Gi0/2 156 R B Linux Uni Gi0/2
sw2#show cdp neighbors
Device ID Local Intrfce Holdtme Capability Platform Port ID
sw1 Gi0/0 140 R S I Linux Uni Gi0/0
sw1 Gi0/3 140 R S I Linux Uni Gi0/3
R2 Gi0/2 156 R B Linux Uni Gi0/2
Versuch, über SSH vom SW1-Gerät aus eine Verbindung zu GW2 herzustellen:
sw1#ssh –l root 10.76.76.138
Password:
S-Terra Gate 4.2.18201 (amd64)
root@GW2~#
Schlussfolgerung: Die Standorte 1 und 2 sind transparent in einer einzigen Broadcast-Domäne verknüpft. Ich werde prüfen, ob der Kanal verschlüsselt ist:
IPSec-Tunnelstatistik auf dem GW1-Gerät:
root@GW1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded
ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 2 (192.168.10.1,500)-(192.168.10.2,500) active 31378 31502
IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 2 (192.168.10.1,*)-(192.168.10.2,*) 17 ESP tunn 508224 27672
Zwischen 192.168.10.1 und 192.168.10.2 wurde ein IPSec-Tunnel eingerichtet.
Ich habe überprüft, dass nur ESP-Verkehr zwischen SW1- und SW2-Geräten übertragen wird, ohne STP. Hier ist ein Verkehrsdump von der gi0 / 3-Schnittstelle von SW1:

Zusammenfassend
Ich habe drei Tassen Kaffee getrunken - dann habe ich die ganze Nacht nicht geschlafen, aber ich musste keine neue Hardware kaufen und aktualisieren. Vielleicht hat es sich gelohnt, in Version 4.3 erinnerte der Anbieter an L2. Ich denke daran, Version 4.3 zum Testen zu nehmen.
Anonymer Ingenieur
t.me/anonimous_engineer