Zum Inhalt springen
Multi-Cloud-Netzwerk

IPsec

Der CE baut IPsec-Tunnel zu den regionalen F5-Edges auf. Sind diese ausgefallen, ist der Standort vom globalen Netzwerk isoliert, unabhängig davon, wie gesund er lokal erscheint.

ipsec-status

Abschnitt betitelt „ipsec-status“
Terminal-Fenster
{"command":["ipsec-status"]}
Security Associations (2 up, 0 connecting):
ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io[8]: ESTABLISHED 70 minutes ago, 10.0.1.4[ver.mcn-ce-ha-eastus01.<tenant>.<uuid>.tenant.int.ves.io]...<public-ip>[ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io]
ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io{9}:  INSTALLED, TUNNEL, reqid 65542, ESP in UDP SPIs: ffff1700_i ffffce10_o
ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io{9}:   10.0.1.4/32 === <public-ip>/32
ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io[7]: ESTABLISHED 70 minutes ago, 10.0.1.4[ver.mcn-ce-ha-eastus01.<tenant>.<uuid>.tenant.int.ves.io]...<public-ip>[ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io]
ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io{8}:  INSTALLED, TUNNEL, reqid 65541, ESP in UDP SPIs: ffff1160_i ffff1e70_o
ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io{8}:   10.0.1.4/32 === <public-ip>/32

Die erste Zeile ist die Antwort: Security Associations (2 up, 0 connecting). Alles unter connecting ist ein Tunnel, der versucht aufzubauen, aber scheitert.

Jede SA benennt den regionalen Edge, an dem sie endet — ny8-nyc, dc12-ash sind F5-POP-Codes — so ist auch erkennbar, mit welchen Edges der Standort verbunden ist.

ESTABLISHED mit einer Laufzeit, gefolgt von INSTALLED, TUNNEL, ist ein gesundes Paar: Ersteres ist die IKE-Sitzung, Letzteres die untergeordnete SA, die tatsächlich den Datenverkehr überträgt. Eine aufgebaute IKE-Sitzung ohne installierte untergeordnete SA ist der interessante Fehlerfall.

ipsec-statusall

Abschnitt betitelt „ipsec-statusall“

Dieselben Informationen zuzüglich SA-bezogener Byte- und Paketzähler, Erneuerungstimer und der ausgehandelten Algorithmen.

Terminal-Fenster
{"command":["ipsec-statusall"]}
Status of IKE charon daemon (strongSwan 5.9.13, Linux 5.14.0-687.20.1.el9_8.x86_64, x86_64):
  uptime: 78 minutes, since Aug 03 15:12:39 2026
  malloc: sbrk 3428352, mmap 0, used 2019536, free 1408816
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 20
  loaded plugins: charon aes des rc2 sha2 sha1 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs12 pgp dnskey sshkey pem openssl pkcs8 fips-prf gmp curve25519 xcbc cmac hmac kdf gcm drbg attr kernel-pb kernel-netlink resolve socket-default stroke vici updown xauth-generic error-notify counters
Listening IP addresses:
  10.0.2.4
  10.0.3.4
  100.64.255.1
  10.0.1.4
  169.254.100.1
  169.254.10.13
  169.254.254.103
Connections:
ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io:  10.0.1.4[4500]...<public-ip>[4500]  IKEv1/2, dpddelay=3s
ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io:   local:  [ver.mcn-ce-ha-eastus01.<tenant>.<uuid>.tenant.int.ves.io] uses any authentication
ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io:    cert:  "O=Volterra, OU=ves-system, CN=ike"
ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io:   remote: [ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io] uses any authentication
ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io:   child:  dynamic === 0.0.0.0/0 TUNNEL, dpdaction=start
ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io:  10.0.1.4[4500]...<public-ip>[4500]  IKEv1/2, dpddelay=3s
ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io:   local:  [ver.mcn-ce-ha-eastus01.<tenant>.<uuid>.tenant.int.ves.io] uses any authentication
ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io:    cert:  "O=Volterra, OU=ves-system, CN=ike"
ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io:   remote: [ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io] uses any authentication
ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io:   child:  dynamic === 0.0.0.0/0 TUNNEL, dpdaction=start
Security Associations (2 up, 0 connecting):
ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io[8]: ESTABLISHED 70 minutes ago, 10.0.1.4[ver.mcn-ce-ha-eastus01.<tenant>.<uuid>.tenant.int.ves.io]...<public-ip>[ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io]
ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io[8]: IKEv2 SPIs: 82b18316b81c76c1_i* 4a79a978d19b3304_r, any reauthentication in 2 hours
ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io[8]: IKE proposal: AES_GCM_16_128/PRF_HMAC_SHA2_256/MODP_3072
ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io{9}:  INSTALLED, TUNNEL, reqid 65542, ESP in UDP SPIs: ffff1700_i ffffce10_o
ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io{9}:  AES_GCM_16_128, 0 bytes_i, 0 bytes_o, rekeying disabled
ver.ny8-nyc.ves-io.<uuid>.tenant.int.ves.io{9}:   10.0.1.4/32 === <public-ip>/32
ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io[7]: ESTABLISHED 70 minutes ago, 10.0.1.4[ver.mcn-ce-ha-eastus01.<tenant>.<uuid>.tenant.int.ves.io]...<public-ip>[ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io]
ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io[7]: IKEv2 SPIs: 7ec7d8a8178881fb_i* e683f63a81425ff5_r, any reauthentication in 2 hours
ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io[7]: IKE proposal: AES_GCM_16_128/PRF_HMAC_SHA2_256/MODP_3072
ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io{8}:  INSTALLED, TUNNEL, reqid 65541, ESP in UDP SPIs: ffff1160_i ffff1e70_o
ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io{8}:  AES_GCM_16_128, 0 bytes_i, 0 bytes_o, rekeying disabled
ver.dc12-ash.ves-io.<uuid>.tenant.int.ves.io{8}:   10.0.1.4/32 === <public-ip>/32

Damit lässt sich unterscheiden, ob „der Tunnel aktiv ist” und ob „der Tunnel tatsächlich Datenverkehr überträgt”. Ein seit Stunden aufgebauter Tunnel mit nahezu null Bytes ist aktiv, aber ungenutzt – was in der Regel bedeutet, dass das Problem im Routing liegt und nicht im Tunnel selbst.