Inhalt

Problem

Die Bereitstellung des Connectors für sichere Zugriffsressourcen im Docker war nicht erfolgreich.

Obwohl der Connector richtig installiert wurde, konnte keine Verbindung zu Cisco Secure Access hergestellt werden.

Diagnoseprüfungen haben einen Tunnelabbruch und Fehler bei der Serverkommunikation gemeldet.

Die Umgebung verwendet virtuelle Red Hat 9-Systeme, die in Google Cloud gehostet werden und über eine Fortinet-Firewall mit einer "any any"-Regel verbunden sind.

Die Fehlerbehebung hat potenzielle MTU-Diskrepanzen zwischen den Netzwerkschnittstellen als wichtigen Faktor aufgedeckt.

Umwelt

- Technologie: Solution Support (SSPT - Vertrag erforderlich)

- Subtechnologie: Sicherer Zugriff - Ressourcen-Connector (Installation, Upgrade, Registrierung, Konnektivität, private Ressource)

- Plattform: Red Hat 9 virtuelle Maschinen auf Google Cloud

- Netzwerk: Fortinet-Firewall zwischen sicherem Zugriff und VM (beliebige Regel vorhanden)

- Connector-Region: iuvz83r.mxc1.acgw.sse.cisco.com

- Google Cloud vPC-Standard-MTU: 1.460 Byte

- Docker-Bridge (docker0) Standard-MTU: 1.500 Byte (vor Änderung)

- Eine Netzwerkschnittstelle (eth0) pro VM

Auflösung

Gehen Sie folgendermaßen vor, um Verbindungsprobleme mit Secure Access Resource Connector in einer Docker-/Google Cloud-Umgebung zu diagnostizieren und zu beheben:

Überprüfen der DNS-Auflösung für die Connector-Region

Verwenden Sie nslookup, um zu bestätigen, dass der sichere Zugriffsbereich vom virtuellen System aufgelöst werden kann.

nslookup iuvz83r.mxc1.acgw.sse.cisco.com

Beispiel:

Server:         64.102.6.247

Address:        64.102.6.247#53

Non-authoritative answer:

Name:   iuvz83r.mxc1.acgw.sse.cisco.com

Address: 163.129.128.72

Name:   iuvz83r.mxc1.acgw.sse.cisco.com

Address: 163.129.128.70

Name:   iuvz83r.mxc1.acgw.sse.cisco.com

Address: 163.129.128.66

Name:   iuvz83r.mxc1.acgw.sse.cisco.com

Address: 163.129.128.68

Netzwerkverbindungen für sicheren Zugriff überprüfen

Verwenden Sie Ping und Telnet, um die Verbindung mit sicherem Zugriff vom virtuellen System aus zu validieren.

ping iuvz83r.mxc1.acgw.sse.cisco.com

Beispiel:

PING iuvz83r.mxc1.acgw.sse.cisco.com (163.129.128.66) 56(84) bytes of data.

64 bytes from 163.129.128.66: icmp_seq=1 ttl=57 time=44.7 ms

64 bytes from 163.129.128.66: icmp_seq=2 ttl=57 time=43.8 ms

...

telnet iuvz83r.mxc1.acgw.sse.cisco.com 443

Beispiel:

Trying 163.129.128.66...

Connected to iuvz83r.mxc1.acgw.sse.cisco.com.

Escape character is '^]'.

Überprüfen der Tunnelverbindung und Durchführen einer Diagnose

Führen Sie das Connector-Diagnosedienstprogramm aus, um den Tunnelstatus zu überprüfen.

/opt/connector/data/bin/diagnostic

Beispiel:

###check tunnel connection:

error: tunnel is not connected

Überprüfung der Netzwerkschnittstelle und der MTU-Einstellungen

Überprüfen Sie die IP-Adressen und die MTU aller Schnittstellen mithilfe von ifconfig und ip a.

ifconfig

ip a

Beispielausgabe für eth0 und docker0:

[root@degcpprcra02 ~]# ifconfig

docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500

inet x.x.x.x netmask x.x.x.x broadcast x.x.x.x

inet6 fe80::1c66:46ff:fe1d:8bed prefixlen 64 scopeid 0x20<link>

ether 1e:66:46:1d:8b:ed txqueuelen 0 (Ethernet)

RX packets 974 bytes 119775 (116.9 KiB)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 848 bytes 161554 (157.7 KiB)

TX errors 0 dropped 2 overruns 0 carrier 0 collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460

inet x.x.x.x netmask x.x.x.x broadcast 0.0.0.0

ether 42:01:c0:a8:80:b0 txqueuelen 1000 (Ethernet)

RX packets 20175 bytes 7755728 (7.3 MiB)

RX errors 0 dropped 0 overruns 0 frame 0

TX packets 21550 bytes 31402300 (29.9 MiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Überprüfen, ob TCP-Datenverkehr erfasst wird

Verwenden Sie tcpdump, um den Datenverkehr zwischen dem virtuellen System und der Secure Access-Region zu erfassen.

tcpdump -i eth0 host iuvz83r.mxc1.acgw.sse.cisco.com

Beispielausgabe (ohne erfasste Pakete):

listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

^C

0 packets captured

6 packets received by filter

0 packets dropped by kernel

Zerstören Sie den Anschluss, und installieren Sie ihn bei Bedarf neu.

Beenden und zerstören Sie den Steckverbinder, wenn Diagnose und technischer Support nicht funktionieren:

/opt/connector/install/connector.sh stop --destroy

cd /opt

rm -rf connector

Installieren Sie den Anschluss neu, und erzeugen Sie eine Ausgabe des technischen Supports.

Generieren Sie nach der Neuinstallation den technischen Support, um Fehlerprotokolle zu erfassen:

/opt/connector/data/bin/techsupport > techsupport.txt

Sample output showing connection errors:

2026-02-13 23:48:20.398772500  >> warning: Connection attempt has failed.

2026-02-13 23:48:20.398775500  >> warning: Unable to contact iuvz83r.mxc1.acgw.sse.cisco.com.

2026-02-13 23:48:20.398775500  >> error: Connection attempt has failed due to server communication errors. Please retry the connection.

2026-02-13 23:48:20.398887500  >> state: Disconnected

Anpassen der Docker-MTU an die Google Cloud VPC- und VM-Schnittstelle

Ändern Sie die MTU auf der Docker-Bridge-Schnittstelle so, dass sie der Google Cloud VPC-Standardeinstellung entspricht (1460 Byte):

ip link set dev docker0 mtu 1460

Überprüfen Sie die MTU-Änderung:

ip a

Beispiel:

docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default

link/ether 1e:66:46:1d:8b:ed brd ff:ff:ff:ff:ff:ff

inet x.x.x.x brd x.x.x.x scope global docker0

valid_lft forever preferred_lft forever

inet6 fe80::1c66:46ff:fe1d:8bed/64 scope link

valid_lft forever preferred_lft forever

Persist Docker MTU-Änderung in /etc/docker/daemon.json

Bearbeiten Sie /etc/docker/daemon.json, und fügen Sie den mtu-Wert hinzu bzw. aktualisieren Sie ihn:

{

...

"mtu": 1460

}

Starten Sie das virtuelle System neu, um die MTU-Konfiguration anzuwenden.

Starten Sie das gesamte virtuelle System neu, um sicherzustellen, dass die MTU-Einstellungen vollständig angewendet werden. Dies ist erforderlich, da es möglich ist, dass ein Neustart nur des Docker-Diensts nicht die MTU-Änderung für alle Netzwerkkomponenten erzwingt.

Nachdem diese Schritte ausgeführt wurden, wurde die Verbindung mit sicherem Zugriff erfolgreich hergestellt, und die Konfiguration konnte abgeschlossen werden.

Ursache

Die Ursache war eine MTU-Diskrepanz zwischen der Docker-Bridge-Schnittstelle (docker0) und der Google Cloud VPC/VM-Netzwerkschnittstelle (eth0). Die Google Cloud VPC- und VM-Schnittstellen verwenden standardmäßig eine MTU von 1460 Byte, während die Docker-Standard-MTU 1500 Byte beträgt.

Diese Diskrepanz verursachte eine Fragmentierung oder verworfene Pakete, wodurch der Secure Access Resource Connector keinen Tunnel erstellen konnte. Durch das Ausrichten der MTU-Werte wurde das Verbindungsproblem behoben.

Verwandte Inhalte

- https://securitydocs.cisco.com/docs/csa/olh/120695.dita

- https://securitydocs.cisco.com/docs/csa/olh/120776.dita

- https://securitydocs.cisco.com/docs/csa/olh/120727.dita

- https://securitydocs.cisco.com/docs/csa/olh/120772.dita

- https://securitydocs.cisco.com/docs/csa/olh/120762.dita

- https://securitydocs.cisco.com/docs/csa/olh/120685.dita

- Technischer Support und Downloads von Cisco