مسألة
لم تنجح محاولات نشر "موصل موارد الوصول الآمن" على جهاز الإرساء.
على الرغم من تثبيت الموصل بشكل صحيح، تعذر إنشاء اتصال ب Cisco Secure Access.
عمليات الفحص التشخيصية التي تم الإعلام عنها لفصل النفق وأخطاء اتصال الخادم.
تستخدم البيئة أجهزة Red Hat 9 الافتراضية التي تستضيفها شركة Google Cloud، والتي يتم توصيلها عبر جدار حماية Fortinet مع قاعدة "أي".
كشف أستكشاف الأخطاء وإصلاحها عن عدم تطابق MTU المحتمل بين واجهات الشبكة كعامل مساهم.
البيئة
- التقنية: دعم الحلول (SSPT - العقد مطلوب)
- التقنية الفرعية: Secure Access - Resource Connector (تثبيت، ترقية، تسجيل، اتصال، مورد خاص)
- النظام الأساسي: الأجهزة الافتراضية Red Hat 9 على Google Cloud
- الشبكة: جدار حماية Fortinet بين Secure Access و VM ("أي" قاعدة موجودة)
- منطقة الموصل: iuvz83r.mxc1.acgw.sse.cisco.com
- وحدة الحد الأقصى الافتراضية ل Google Cloud VPC: 1460 بايت
- Docker Bridge (docker0) MTU الافتراضي: 1500 بايت (قبل التغيير)
- واجهة شبكة واحدة (eth0) لكل VM
قرار
اتبع هذه الخطوات لتشخيص مشاكل اتصال موصل موارد الوصول الآمن وحلها في بيئة Docker/Google Cloud:
التحقق من دقة DNS لمنطقة الموصل
أستخدم nslookup لتأكيد إمكانية حل منطقة الوصول الآمن من الجهاز الظاهري.
nslookup iuvz83r.mxc1.acgw.sse.cisco.com
مثال الإخراج:
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
فحص اتصال الشبكة للوصول الآمن
أستخدم ping وtelnet للتحقق من الاتصال للوصول الآمن من الجهاز الظاهري.
ping iuvz83r.mxc1.acgw.sse.cisco.com
مثال الإخراج:
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
مثال الإخراج:
Trying 163.129.128.66...
Connected to iuvz83r.mxc1.acgw.sse.cisco.com.
Escape character is '^]'.
التحقق من اتصال النفق وتشغيل التشخيصات
قم بتشغيل الأداة المساعدة لتشخيص الموصل للتحقق من حالة النفق.
/opt/connector/data/bin/diagnostic
مثال الإخراج:
###check tunnel connection:
error: tunnel is not connected
التحقق من واجهة الشبكة وإعدادات MTU
تحقق من عناوين IP و MTU لجميع الواجهات باستخدام ifconfig وip a.
ifconfig
ip a
مثال إخراج ل eth0 و 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
التحقق من التقاط حركة مرور TCP
أستخدم tcpdump لالتقاط حركة مرور البيانات بين منطقة الوصول الآمن و VM.
tcpdump -i eth0 host iuvz83r.mxc1.acgw.sse.cisco.com
مثال إخراج (يظهر ما من حزم ملتقطة):
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
إتلاف الموصل وإعادة تثبيته إذا لزم الأمر
قم بإيقاف الموصل وإتلافه في حالة عدم عمل التشخيصات والدعم الفني:
/opt/connector/install/connector.sh stop --destroy
cd /opt
rm -rf connector
إعادة تثبيت الموصل وإنشاء إخراج الدعم الفني
بعد إعادة التثبيت، قم بإنشاء دعم فني لتسجيل سجلات الأخطاء:
/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
ضبط وحدة الحد الأقصى للنقل (MTU) للخادم لمطابقة واجهة Google Cloud VPC و VM
قم بتغيير وحدة الحد الأقصى للنقل (MTU) على واجهة جسر Docker لمطابقة الإعداد الافتراضي ل Google Cloud VPC (1460 بايت):
ip link set dev docker0 mtu 1460
التحقق من تغيير MTU:
ip a
مثال الإخراج:
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
إستمرار تغيير وحدة الحد الأقصى للنقل (MTU) الخاصة بالمستندات في /etc/docker/daemon.json
قم بتحرير /etc/docker/daemon.json وإضافة قيمة MTU أو تحديثها:
{
...
"mtu": 1460
}
قم بإعادة تشغيل الجهاز الافتراضي لتطبيق تكوين وحدة الحد الأقصى للنقل (MTU)
قم بإعادة تشغيل VM بالكامل لضمان تطبيق إعدادات MTU بالكامل. وهذا ضروري، لأنه من الممكن ألا تؤدي إعادة تشغيل خدمة Docker فقط إلى فرض تغيير MTU لجميع مكونات الشبكة.
بعد اتباع هذه الخطوات، تم بنجاح إنشاء اتصال ب Secure Access، ويمكن إكمال التكوين.
السبب
كان السبب الجذري عدم تطابق MTU بين واجهة جسر Docker (docker0) وواجهة شبكة Google Cloud VPC/VM (eth0). واجهات Google Cloud VPC و VM الافتراضية إلى MTU بمقدار 1460 بايت، في حين أن MTU الافتراضي ل Docker هو 1500 بايت.
تسبب عدم التطابق هذا في تجزئة الحزم أو إسقاطها، مما منع Secure Access Resource Connector من إنشاء نفق. أدت محاذاة قيم MTU إلى حل مشكلة الاتصال.
المحتوى ذي الصلة
- 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
- الدعم الفني والتنزيلات من Cisco
التعليقات