يتصل أحد المستخدمين ويفتح التطبيق الداخلي ويحصل على إجابة؛ بينما يحصل زميل على النقطة الطرفية نفسها على مهلة انتهاء من حاسوب مماثل على شبكة Wi-Fi نفسها. هذا النمط هو بصمة نقطة طرفية لـ client VPN مرتبطة بأكثر من شبكة فرعية واحدة، حيث لا تكون المسارات متكافئة. أتتبع الأمر من وحدة التحكم إلى الخارج، لأن علامتي تبويب تحددان ما إذا كان بقية التحقيق يستحق العناء. لا شيء في إعدادات العميل يفسر ذلك.

ابدأ من النقطة الطرفية واسرد الارتباطات

في وحدة تحكم VPC، افتح Client VPN endpoints، واختر النقطة الطرفية واقرأ علامة تبويب Associations. كل ارتباط هو شبكة فرعية في منطقة توفر، والعميل يهبط على الشبكة التي تختارها الخدمة عند إنشاء الاتصال. دوّن معرّفات الشبكات الفرعية وجدول المسارات الذي يستخدمه كل منها فعلاً، لأن هاتين القائمتين هما المقارنة التي أنت على وشك إجرائها.

إذا أظهرت النقطة الطرفية ارتباطاً واحداً فقط، فهذه النظرية خاطئة والعميل هو المشتبه به الأفضل.

قارن جدول مسارات النقطة الطرفية بكل ارتباط

افتح علامة تبويب Route table على النقطة الطرفية نفسها. لكل CIDR وجهة هناك هدف، وفي client VPN يكون الهدف ارتباطاً لا بوابة. تشترط AWS إدخال وجهة لكل شبكة فرعية مرتبطة، لذا فإن مساراً يستهدف واحدة فقط منها يجعل الوصول معتمداً على المكان الذي هبطت فيه الجلسة. افحص الوجهة التي تهمك فعلاً، ثم افحص قاعدة التفويض الخاصة بها، لأن المسار يوفر الطريق والقاعدة تقرر من يحق له استخدامه.

بمجرد أن تجدول الطبقتين، يصبح الخلل صعباً في تفويته.

Associated subnetEndpoint route to 10.200.0.0/16VPC route in that subnet
subnet-aaaTargets the association10.200.0.0/16 to pcx-example
subnet-bbbTargets the associationNo matching entry

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

تتبّع كل شبكة فرعية إلى جدول مساراتها الفعلي

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

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

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

افحص قواعد التفويض، ثم مسار العودة

قواعد التفويض تكون لكل وجهة ولكل مجموعة، وتُقيَّم بشكل منفصل عن المسارات. الوجهة التي لها مسارات في كل مكان لكن لا قاعدة لمجموعة المستخدم تتصرف كثقب أسود مع جدول مسارات يبدو سليماً.

مسار العودة يستحق الاهتمام نفسه. اتصال الاقتران يحتاج إلى مسار في VPC الخاص بالتطبيق يشير عائداً إلى CIDR الخاص بالعميل، وقواعد مجموعات أمان تسمح بالمرور عند الطرفين، وقوائم ACL للشبكة لا تُسقطه. إمكانية الوصول أحادية الاتجاه، حيث يعمل ping ولا تعمل مصافحة TCP، تشير عادة إلى ACL أو مجموعة أمان لا إلى VPN.

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

تحقق بإعادة اتصال، لا بطلب محظوظ واحد

مع النفق المنقسم، تُدفع مسارات النقطة الطرفية عند إنشاء الاتصال، لذا فإن مجموعة مسارات متغيرة لا تصل أبداً إلى عميل يبقى متصلاً. افصل الاتصال وأعد الاتصال عبر العميل المدعوم، ثم تأكد من وجود المسارات الجديدة على الجهاز.

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

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