802.1Q für die Verwaltung von GOST L2VPN oder wie Sie bei Software-Updates Geld sparen können





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



All Articles