ProHoster > Blog > Administration > 1.5 Schemata zu inlÀndischen IPsec VPN. Teste Demoversionen

1.5 Schemata zu inlÀndischen IPsec VPN. Teste Demoversionen

1.5 Schemata zu inlÀndischen IPsec VPN. Teste Demoversionen

Situation

Ich habe die Demoversion der S-Terra VPN-Produkte Version 4.3 fĂŒr drei Monate erhalten. Ich möchte herausfinden, ob mein Ingenieursalltag nach dem Wechsel zur neuen Version einfacher wird.

Heute ist es nicht kompliziert, ein PÀckchen löslichen Kaffee 3 in 1 sollte ausreichen. Ich werde erklÀren, wie man Demoversionen erhÀlt. Ich werde versuchen, GRE-over-IPsec und IPsec-over-GRE-Schemata zusammenzustellen.

So erhÀlt man eine Demoversion

1.5 Schemata zu inlÀndischen IPsec VPN. Teste Demoversionen

Aus der Abbildung geht hervor, dass man zur Erlangung der Demoversion Folgendes tun muss:

  • Eine E-Mail an presale@s-terra.ru von der Unternehmensadresse schreiben;
  • Im Schreiben die Steuernummer Ihrer Organisation angeben;
  • Die Produkte und deren Anzahl auflisten.

Demoversionen sind drei Monate gĂŒltig. Der Hersteller beschrĂ€nkt deren FunktionalitĂ€t nicht.

Ich entfaltet das Image

Die Demoversion des Sicherheitsgateways ist ein Bild der virtuellen Maschine. Ich benutze VMWare Workstation. Eine vollstĂ€ndige Liste der unterstĂŒtzten Hypervisoren und Virtualisierungsumgebungen ist auf der Website des Herstellers zu finden.

Bevor Sie mit aktiven Maßnahmen beginnen, beachten Sie bitte, dass im Bild der virtuellen Maschine standardmĂ€ĂŸig keine Netzwerkinterfaces vorhanden sind:

1.5 Schemata zu inlÀndischen IPsec VPN. Teste Demoversionen

Die Logik ist klar, der Benutzer muss so viele Interfaces hinzufĂŒgen, wie er benötigt. Ich werde gleich vier hinzufĂŒgen:

1.5 Schemata zu inlÀndischen IPsec VPN. Teste Demoversionen

Jetzt starte ich die virtuelle Maschine. Unmittelbar nach dem Start verlangt das Gateway einen Benutzernamen und ein Passwort.

Im S-Terra Gateway gibt es mehrere Konsolen mit unterschiedlichen Konten. Ich werde ihre Anzahl in einem separaten Artikel zÀhlen. Und vorerst:
Anmelden als: Administrator
Passwort: s-terra

Ich initialisiere das Gateway. Die Initialisierung ist eine Folge von Aktionen: Eingabe der Lizenz, Einstellung des biologischen Zufallszahlengenerators (Tastaturtrainer – mein Rekord sind 27 Sekunden) und Erstellung der Netzwerkschnittstellenkarten.

Netzwerkschnittstellenkarte. Es wurde einfacher

Version 4.2 begrĂŒĂŸte aktive Benutzer mit Nachrichten:

IPsec-Daemon starten
.. fehlgeschlagen
FEHLER: Verbindung zum Daemon konnte nicht hergestellt werden

Ein aktiver Benutzer (laut anonymem Ingenieur) ist ein Benutzer, der alles schnell und ohne Dokumentation einrichten kann.

Etwas lief schief, schon bevor ich versuchte, die IP-Adresse auf dem Interface einzustellen. Das Problem lag in der Netzwerkschnittstellenkarte. Es musste Folgendes durchgefĂŒhrt werden:

/bin/netifcfg enum > /home/map
/bin/netifcfg map /home/map
Netzwerkdienst neu starten

Das Ergebnis ist eine Netzwerkschnittstellenkarte, die das Mapping der Namen der physischen Schnittstellen (0000:02:03.0) und deren logischen Bezeichnungen im Betriebssystem (eth0) und in der Cisco-Àhnlichen Konsole (FastEthernet0/0) enthÀlt:

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

Logische Bezeichnungen der Schnittstellen werden Aliase genannt. Aliase werden in der Datei /etc/ifaliases.cf gespeichert.
In der Version 4.3 wird beim ersten Start der virtuellen Maschine die Schnittstellenkarte automatisch erstellt. Wenn Sie die Anzahl der Netzwerkschnittstellen in der virtuellen Maschine Àndern, seien Sie so nett, die Schnittstellenkarte erneut zu erstellen:

/bin/netifcfg enum > /home/map
/bin/netifcfg map /home/map
systemctl neustarten Netzwerke

Schema 1: GRE-over-IPsec

Ich richte zwei virtuelle Gateways ein, verbinde sie wie im Bild gezeigt:

1.5 Schemata zu inlÀndischen IPsec VPN. Teste Demoversionen

Schritt 1. Konfiguriere IP-Adressen und Routen

VG1(config) #
interface fa0/0
ip address 172.16.1.253 255.255.255.0
no shutdown
interface fa0/1
ip address 192.168.1.253 255.255.255.0
no shutdown
ip route 0.0.0.0 0.0.0.0 172.16.1.254

VG2(config) #
interface fa0/0
ip address 172.16.1.254 255.255.255.0
no shutdown
interface fa0/1
ip address 192.168.2.254 255.255.255.0
no shutdown
ip route 0.0.0.0 0.0.0.0 172.16.1.253

ÜberprĂŒfe die IP-KonnektivitĂ€t:

root@VG1:~# ping 172.16.1.254 -c 4
PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.545 ms
64 bytes from 172.16.1.254: icmp_seq=2 ttl=64 time=0.657 ms
64 bytes from 172.16.1.254: icmp_seq=3 ttl=64 time=0.687 ms
64 bytes from 172.16.1.254: icmp_seq=4 ttl=64 time=0.273 ms

--- 172.16.1.254 ping-Statistiken ---
4 Pakete ĂŒbertragen, 4 empfangen, 0% Paketverlust, Zeit 3005ms
rtt min/avg/max/mdev = 0.273/0.540/0.687/0.164 ms

Schritt 2. GRE konfigurieren

Ich entnehme das Beispiel fĂŒr die GRE-Konfiguration aus offiziellen Szenarien. Ich erstelle die Datei gre1 im Verzeichnis /etc/network/interfaces.d mit dem Inhalt.

FĂŒr VG1:

auto gre1
iface gre1 inet static
address 1.1.1.1
netmask 255.255.255.252
pre-up ip tunnel add gre1 mode gre remote 172.16.1.254 local 172.16.1.253 key 1 ttl 64 tos inherit
pre-up ethtool -K gre1 tx off > /dev/null
pre-up ip link set gre1 mtu 1400
post-down ip link del gre1

FĂŒr VG2:

auto gre1
iface gre1 inet static
address 1.1.1.2
netmask 255.255.255.252
pre-up ip tunnel add gre1 mode gre remote 172.16.1.253 local 172.16.1.254 key 1 ttl 64 tos inherit
pre-up ethtool -K gre1 tx off > /dev/null
pre-up ip link set gre1 mtu 1400
post-down ip link del gre1

Ich aktiviere die Schnittstelle im System:

root@VG1:~# ifup gre1
root@VG2:~# ifup gre1

ÜberprĂŒfe:

root@VG1:~# ip address show
8: gre1@NONE:  mtu 1400 qdisc noqueue state UNKNOWN group default qlen 1
    link/gre 172.16.1.253 peer 172.16.1.254
    inet 1.1.1.1/30 brd 1.1.1.3 scope global gre1
       valid_lft forever preferred_lft forever

root@VG1:~# ip tunnel show
gre0: gre/ip remote any local any ttl inherit nopmtudisc
gre1: gre/ip remote 172.16.1.254 local 172.16.1.253 ttl 64 tos inherit key 1

In C-Terra Gateway gibt es einen integrierten Paket-Sniffer – tcpdump. Ich werde den Datenverkehr in eine pcap-Datei aufzeichnen:

root@VG2:~# tcpdump -i eth0 -w /home/dump.pcap

Starte ein Ping zwischen den GRE-Schnittstellen:

root@VG1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.918 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.850 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.918 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.974 ms

--- 1.1.1.2 Ping-Statistiken ---
4 Pakete ĂŒbertragen, 4 empfangen, 0% Paketverlust, Zeit 3006ms
rtt min/avg/max/mdev = 0.850/0.915/0.974/0.043 ms

Der GRE-Tunnel ist aktiv und funktioniert:

1.5 Schemata zu inlÀndischen IPsec VPN. Teste Demoversionen

Schritt 3. VerschlĂŒsselung von GRE mit GOST

Ich lege die Identifikation anhand der Adresse fest. Die Authentifizierung erfolgt ĂŒber einen vordefinierten SchlĂŒssel (laut Nutzungsbedingungen sollten digitale Zertifikate verwendet werden):

VG1(config)#
crypto isakmp identitÀt adresse
crypto isakmp schlĂŒssel KEY adresse 172.16.1.254

Ich setze die IPsec Phase I Parameter:

VG1(config)#
crypto isakmp policy 1
ecr gost
hash gost3411-256-tc26
auth pre-share
group vko2

Ich setze die IPsec Phase II Parameter:

VG1(config)#
crypto ipsec transform-set TSET esp-gost28147-4m-imit
modus tunnel

Ich erstelle eine Zugriffsliste fĂŒr die VerschlĂŒsselung. Zielverkehr — GRE:

VG1(config)#
ip access-list extended LIST
permit gre host 172.16.1.253 host 172.16.1.254

Ich erstelle eine Kryptokarte und verknĂŒpfe sie mit dem WAN-Interface:

VG1(config)#
crypto map CMAP 1 ipsec-isakmp
match address LIST
set transform-set TSET
set peer 172.16.1.253
interface fa0/0
  crypto map CMAP

FĂŒr VG2 ist die Konfiguration spiegelbildlich, Unterschiede:

VG2(config)#
crypto isakmp key KEY address 172.16.1.253
ip access-list extended LIST
permit gre host 172.16.1.254 host 172.16.1.253
crypto map CMAP 1 ipsec-isakmp
set peer 172.16.1.254

ÜberprĂŒfe:

root@VG2:~# tcpdump -i eth0 -w /home/dump2.pcap
root@VG1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes von 1.1.1.2: icmp_seq=1 ttl=64 zeit=1128 ms
64 bytes von 1.1.1.2: icmp_seq=2 ttl=64 zeit=126 ms
64 bytes von 1.1.1.2: icmp_seq=3 ttl=64 zeit=1.07 ms
64 bytes von 1.1.1.2: icmp_seq=4 ttl=64 zeit=1.12 ms

--- 1.1.1.2 ping-statistik ---
4 pakete gesendet, 4 empfangen, 0% paketverlust, zeit 3006ms
rtt min/avg/max/mdev = 1.077/314.271/1128.419/472.826 ms, pipe 2

ISAKMP/IPsec Statistik:

root@VG1:~# sa_mgr show
ISAKMP Sitzungen: 0 initiiert, 0 geantwortet

ISAKMP Verbindungen:
Num Conn-id (Lokale Addr,Port)-(Remotes Addr,Port) Status Gesendet Empfangen
1 1 (172.16.1.253,500)-(172.16.1.254,500) aktiv 1086 1014

IPsec Verbindungen:
Num Conn-id (Lokale Addr,Port)-(Remotes Addr,Port) Protokoll Aktion Typ Gesendet Empfangen
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tunn 480 480

Im Datenverkehrdump sind keine GRE-Pakete vorhanden:

1.5 Schemata zu inlÀndischen IPsec VPN. Teste Demoversionen

Fazit: Das GRE-over-IPsec-Schema funktioniert einwandfrei.

Schema 1.5: IPsec-over-GRE

Ich plane nicht, IPsec-over-GRE im Netzwerk zu verwenden. Ich baue es auf, weil ich es möchte.

1.5 Schemata zu inlÀndischen IPsec VPN. Teste Demoversionen

Um das GRE-over-IPsec-Schema umzukehren, muss man:

  • Die Zugriffsliste fĂŒr die VerschlĂŒsselung anpassen – Zielverkehr von LAN1 nach LAN2 und umgekehrt;
  • Die Routing ĂŒber GRE konfigurieren;
  • Die Kryptokarte am GRE-Interface anhĂ€ngen.

StandardmĂ€ĂŸig gibt es in der Cisco-Ă€hnlichen Konsole des Gateways kein GRE-Interface. Es existiert nur im Betriebssystem.

Ich fĂŒge das GRE-Interface zur Cisco-Ă€hnlichen Konsole hinzu. Dazu bearbeite ich die Datei /etc/ifaliases.cf:

interface (name="FastEthernet0/0" pattern="eth0")
interface (name="FastEthernet0/1" pattern="eth1")
interface (name="FastEthernet0/2" pattern="eth2")
interface (name="FastEthernet0/3" pattern="eth3")
interface (name="Tunnel0" pattern="gre1")
interface (name="default" pattern="*")

wo gre1 die Bezeichnung des Interfaces im Betriebssystem ist, Tunnel0 die Bezeichnung des Interfaces in der Cisco-Ă€hnlichen Konsole.

Ich berechne den Hash der Datei neu:

root@VG1:~# integr_mgr calc -f /etc/ifaliases.cf

ERFOLG:  Operation war erfolgreich.

Jetzt ist das Interface Tunnel0 in der Cisco-Ă€hnlichen Konsole erschienen:

VG1# show run
interface Tunnel0
ip adresse 1.1.1.1 255.255.255.252
mtu 1400

Ich passe die Zugriffsliste fĂŒr die VerschlĂŒsselung an:

VG1(config)#
ip access-list extended LIST
permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255

Ich konfiguriere das Routing ĂŒber GRE:

VG1(config)#
no ip route 0.0.0.0 0.0.0.0 172.16.1.254
ip route 192.168.3.0 255.255.255.0 1.1.1.2

Ich entferne die Krypto-Karte von Fa0/0 und binde sie an das GRE-Interface:

VG1(config)#
interface Tunnel0
crypto map CMAP

FĂŒr VG2 analog.

ÜberprĂŒfe:

root@VG2:~# tcpdump -i eth0 -w /home/dump3.pcap

root@VG1:~# ping 192.168.2.254 -I 192.168.1.253 -c 4
PING 192.168.2.254 (192.168.2.254) von 192.168.1.253 : 56(84) Bytes an Daten.
64 Bytes von 192.168.2.254: icmp_seq=1 ttl=64 time=492 ms
64 Bytes von 192.168.2.254: icmp_seq=2 ttl=64 time=1.08 ms
64 Bytes von 192.168.2.254: icmp_seq=3 ttl=64 time=1.06 ms
64 Bytes von 192.168.2.254: icmp_seq=4 ttl=64 time=1.07 ms

--- 192.168.2.254 ping Statistiken ---
4 Pakete ĂŒbertragen, 4 empfangen, 0% Paketverlust, Zeit 3006ms
rtt min/avg/max/mdev = 1.064/124.048/492.972/212.998 ms

ISAKMP/IPsec Statistik:

root@VG1:~# sa_mgr show
ISAKMP-Sitzungen: 0 initiiert, 0 geantwortet

ISAKMP-Verbindungen:
Num Conn-id (Lokale Addr,Port)-(Remote Addr,Port) Zustand Gesendet Empfangen
1 2 (172.16.1.253,500)-(172.16.1.254,500) aktiv 1094 1022

IPsec-Verbindungen:
Num Conn-id (Lokale Addr,Port)-(Remote Addr,Port) Protokoll Aktions Typ Gesendet Empfangen
1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 352 352

Im Datenverkehrs-Dump sind ESP-Pakete, die in GRE gekapselt sind:

1.5 Schemata zu inlÀndischen IPsec VPN. Teste Demoversionen

Fazit: IPsec-over-GRE funktioniert korrekt.

Ergebnisse

Eine Tasse Kaffee hat gereicht. Ich habe eine Anleitung zur Erlangung der Demo-Version skizziert. Ich habe GRE-over-IPsec konfiguriert und umgekehrt implementiert.

Die Netzwerkschnittstellenkarte in Version 4.3 ist automatisch! Ich teste weiter.

Anonymer Ingenieur
t.me/anonimous_engineer

Quelle: habr.com

60GB SSD 8Gb DDR4