AWS Client VPN متصل لكن لا يوجد وصول إلى الإنترنت: فحص المسارات

هل أنت متصل بـ AWS Client VPN بلا وصول إلى الإنترنت؟ افحص مسارات العميل وتفويض نقطة النهاية وخروج الشبكة الفرعية وDNS بهذا الترتيب.

أنت متصل بنقطة نهاية AWS Client VPN، والشبكة الفرعية الخاصة ترد، وكل صفحة عامة ما زالت تنتهي بمهلة. هذا المزيج يضيّق المشكلة إلى واحد من ثلاثة كائنات على الجانب المُدار: المسار الذي يثبّته العميل، أو مسار نقطة النهاية مع قاعدة التفويض الخاصة به، أو القفزة التالية للشبكة الفرعية المرتبطة. أفحصها بهذا الترتيب لأن كل فشل يبدو مختلفًا من جهة العميل. يغطي هذا الدليل نقطة النهاية المُدارة المرتبطة بـ VPC، وليس خادم OpenVPN على نسخة EC2، ولا ارتباط Cloud WAN أو Transit Gateway.

ابدأ بما يوجّهه العميل فعليًا

حالة الاتصال تثبت جلسة TLS وتعيين CIDR للعميل، ولا شيء أكثر. اسأل نظام التشغيل إلى أين سيذهب عنوان عام بينما النفق قائم. على Linux يجب أن يذكر ip route get 1.1.1.1 واجهة النفق؛ وعلى macOS يُظهر netstat -rn -f inet | head -5 الإدخال الافتراضي؛ وعلى Windows يطبع Find-NetRoute -RemoteIPAddress 1.1.1.1 الواجهة المختارة والقفزة التالية.

ثم اقرأ علامة النفق المنقسم، لأنها تحدد ما إذا كانت المسارات المنشورة من نقطة النهاية هي الوجهات الوحيدة التي يرسلها العميل إلى النفق:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

عندما تكون SplitTunnel صحيحة، لا تستخدم وجهة عامة النفق إلا إذا نشرت نقطة النهاية مسارًا يغطيها، لذا فإن غياب 0.0.0.0/0 يترك ذلك التراسل على الواجهة المحلية. وعندما تكون خاطئة، يلتقط العميل التراسل، لكن نقطة النهاية ما زالت ملزمة بتوجيهه وتفويضه؛ وإلا دخلت الحزم النفق وتوقفت هناك. أعد توصيل العميل بعد تغيير أي من الإعدادين، لأن المسارات وخوادم DNS تُسلّم عند وقت الاتصال ويمكن للعميل العامل أن يحتفظ بمجموعته القديمة.

اقرأ مسار نقطة النهاية وقاعدة التفويض بشكل منفصل

هذان كائنان، وإنشاء أحدهما لا ينشئ الآخر. اسرد مسارات نقطة النهاية وابحث عن مسار افتراضي هدفه شبكة فرعية مرتبطة:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

لكل مسار شبكة فرعية هدف واحدة بالضبط، لذا تحتاج ثلاث ارتباطات إلى مسار افتراضي مطابق لكل منها. توثّق AWS هذا الشرط الخاص بالتغطية، والعَرَض العملي للفجوة هو مستخدم يعمل من شبكة فرعية ويتعطل من أخرى، وهو ما يُقرأ كعطل متقطع بدلًا من مسار مفقود. إن وثائق سيناريو Client VPN الرسمية تصف ترتيب الشبكة الفرعية العامة الذي تنتمي إليه هذه المسارات.

التفويض هو الكائن الثاني. عندما لا تغطي أي قاعدة الوجهة العامة، يحمل النفق الحزمة وتتجاهلها الخدمة، فتبقى الموارد الخاصة تعمل بينما لا يعمل الإنترنت:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

قاعدة لـ VPC CIDR لا تقول شيئًا عن 0.0.0.0/0. وإضافة القطع الناقصة لنفق كامل تعني مسارًا واحدًا لكل شبكة فرعية مرتبطة بالإضافة إلى قاعدة تفويض يمكنك مراجعتها لاحقًا:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all تمنح الوجهة لكل عميل في نقطة النهاية، لذا أبقها فقط ما دام النفق مقصودًا أن يكون كاملًا؛ والقاعدة المرتبطة بمجموعة دليل أفضل عندما تكون لديك مجموعات لربطها.

تابع الحزمة خارج الشبكة الفرعية المرتبطة

مسار نقطة النهاية يقرر أن AWS تسلّم الحزمة لتلك الشبكة الفرعية. وهو لا يقرر القفزة التالية بعدها، التي تعيش في جدول مسارات VPC الخاص بالشبكة الفرعية:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

المسار الافتراضي القابل للاستخدام يشير إلى بوابة إنترنت لشبكة فرعية عامة، أو إلى بوابة NAT لشبكة خاصة، وحالة blackhole تعني أن الهدف حُذف وأن المسار يموت الآن بهدوء. هذه جداول مختلفة عن قائمة مسارات نقطة النهاية، وإصلاح أحدهما لا يصلح الآخر.

مرشحان يقفان على هذه القفزة. يجب أن تسمح مجموعة الأمان المطبقة على ارتباط الشبكة الهدف بالتراسل الصادر نحو الوجهة العامة، ويجب أن تسمح أي قائمة تحكم وصول شبكي منطبقة بالطلب وتراسل العودة على المنافذ العابرة. مجموعة أمان ارتباط مقيّدة سبب شائع لنجاح الوصول الخاص وفشل الوصول العام.

اختر الطبقة الأولى من العَرَض بدلًا من تغيير الثلاث معًا:

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

افصل فشل DNS عن مسار ميت

يفشل تحليل الأسماء بشكل مختلف عن التمرير، والنفق الكامل يجعل الفرق مهمًا لأن المُحلِّل المدفوع يُبلغ الآن عبر النفق. إذا حددت نقطة النهاية خوادم DNS الخاصة بـ VPC، فتحتاج عناوينها إلى تغطية مسار وتفويض مثل أي وجهة أخرى. استعلم من المُحلِّل مباشرة لتعرف أي فشل لديك: dig +short example.com @10.0.0.2، أو nslookup example.com 10.0.0.2 على Windows.

عندما يستجيب URL رقمي ولا يستجيب اسم، توقف عن تحرير المسار الافتراضي واعمل على DNS. والطلب إلى عنوان IP لا يثبت شيئًا عن مضيف افتراضي مسمّى وشهادته، لذا أبقِ اختبارًا مسمّى واحدًا في الفحص النهائي.

التوقيت يساعد. اتصال TCP لا يتلقى ردًا خلال ثوانٍ قليلة يشير إلى التوجيه أو مرشح، بينما طلب يتعلق داخل البحث عن الاسم يشير إلى المُحلِّل. تغيير المسار الافتراضي بينما المُحلِّل غير قابل للوصول يحوّل عادة فشلًا واحدًا إلى فشلين.

تراجع بنظافة، ثم تحقق من مسار الخروج

كان الكائنان إضافيين، لذا فالتراجع حذف لا إصلاح:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

أعد التوصيل، ثم أكّد المسار الذي يخرج منه التراسل. قارن العنوان العام الملاحظ بعنوان IP المرن لبوابة NAT، أو ببوابة الإنترنت التي كنت تنوي استخدامها، وتحقق من أن موردًا خاصًا ما زال يستجيب في الجلسة نفسها.

اختم بقائمة قصيرة، وتعامل مع العنصر الأخير كجزء من التغيير لا كتوثيق:

  • مسار 0.0.0.0/0 واحد لنقطة النهاية لكل شبكة فرعية مرتبطة.
  • قاعدة تفويض تغطي 0.0.0.0/0 للعملاء الذين تقصد خدمتهم.
  • مسار افتراضي لـ VPC غير مصاب بحالة blackhole على كل شبكة فرعية مرتبطة.
  • خروج مجموعة أمان الارتباط، بالإضافة إلى تراسل عودة ACL.
  • عناوين المُحلِّل موجّهة ومفوّضة، مُتحقّق منها بطلب مسمّى.
  • تراجع مسجّل للمسار وللقاعدة.

ملاحظة نطاق واحدة: هذا مسار IPv4. يحتفظ عميل ثنائي المكدس بأي اتصال IPv6 لديه بالفعل، لذا فالمسار الافتراضي IPv6 قرار منفصل بتفويضه الخاص وليس أثرًا جانبيًا لهذا القرار.

مقالات ذات صلة