النفق الكامل في Access Server على EC2: لماذا لا يكفي مربع اختيار واحد

تعطيل فحص المصدر والوجهة على نسخة EC2 هو الجواب الأكثر تكرارا على أسئلة خروج Access Server إلى الإنترنت، وهو وحده لا يفعل شيئا لعملائك. الفحص قيد إعادة توجيه في AWS: يجعل النسخة تقبل حزما ليس مصدرها أو وجهتها عنوانها. وهو لا يطلب من عميل Access Server إرسال حركة الإنترنت عبر النفق، ولا ينشئ مسارا صاعدا، ولا يضيف NAT. الأسطورة أن مربع الاختيار هو الميزة.

ما الذي يتحكم فيه الفحص فعلا

كل واجهة شبكة في EC2 تُسقط الحركة غير الموجهة إليها، إلا إذا كانت النسخة تعمل كموجّه أو جهاز NAT أو بوابة VPN وكنت قد عطّلت ذلك الفحص. تعطيله يمنح إذن إعادة التوجيه. والإذن ليس إعدادا: فالنسخة ما زالت تحتاج مسارا إلى بوابة إنترنت أو جهاز NAT، وجدول مسارات VPC ما زال يحتاج المدخل المطابق، ومجموعات الأمان ما زالت عليها السماح بالتدفق، وعلى الخادم أن يترجم حركة العودة أو يوجّهها.

تحقق من القيمة الحالية باستخدام aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck قبل تغيير أي شيء. وإن غيّرتها من وحدة التحكم، فغيّرها لأن النسخة تعيد التوجيه لغيرها، لا لأن عميلا لا يصل إلى الإنترنت.

Access Server يملك سياسة توجيه العميل

في Access Server 3، افتح Access Controls وابحث عن قسم Internet Access and DNS. يقدّم اختيار Internet Gateway نفقا كاملا أو نفقا منقسما؛ النفق الكامل يطلب من العميل توجيه حركته الافتراضية إلى داخل VPN، والنفق المنقسم يترك حركة الإنترنت على مسار العميل المحلي. احفظ وطبّق عبر سير عمل المنتج، ثم أعد توصيل عميل اختباري، لأن السياسة تُسلَّم وقت الاتصال.

الإصدارات الأقدم تستخدم قوائم مختلفة، وبعض إصدارات Community من OpenVPN لا تملك تحكما مكافئا. تحقق من الإصدار الرئيسي المثبّت قبل البحث عن شاشة غير موجودة. ثم أكّد ما تلقاه العميل: ملف النفق الكامل يجب أن يثبّت مسارا افتراضيا عبر النفق، وملف النفق المنقسم يجب ألا يفعل ذلك.

تتبّع الحزمة بعد النفق

حين يرسل العميل حركة الإنترنت إلى النفق، على الخادم إعادة توجيهها وترجمتها عادة. يدير Access Server قواعد NAT والتوجيه الخاصة به، فاقرأ الإعداد الفعلي بدلا من إضافة قواعد Community OpenVPN إلى الملفات المولّدة؛ فالقواعد غير المُدارة تُستبدل أو تتعارض عند التحديث التالي للمنتج. يوضح sudo iptables -t nat -L -n -v أو مكافئه في nftables ما يترجم فعلا.

جانب AWS مسار منفصل. نسخة في شبكة فرعية عامة تصل إلى بوابة إنترنت مباشرة وتحتفظ بعنوانها العام أو بعنوان elastic IP. ونسخة في شبكة فرعية خاصة تحتاج مسارا إلى بوابة NAT أو إلى نسخة NAT، ويحتاج جهاز NAT بدوره مسارا إلى بوابة الإنترنت. وربط بوابة إنترنت بـ VPC لا يمنح أي مصدر خاص عنوان عودة عاما بحد ذاته، ولهذا يعمل الإعداد نفسه في شبكة فرعية ويفشل بصمت في أخرى.

افحص جدول المسارات المرتبط بالشبكة الفرعية للنسخة، لا الجدول الرئيسي لـ VPC فقط. ارتباطات الشبكات الفرعية تتجاوز الجدول الرئيسي، والارتباط القديم سبب شائع لتوقف إعداد كان يعمل بعد إعادة البناء.

افصل خروج IP عن DNS

اختبر عنوانا حرفيا أولا ثم اسما، من التطبيق نفسه على العميل. إن أعاد curl -4 https://checkip.amazonaws.com عنوانا عاما بينما فشلت أسماء المضيفين، فالنفق ومسار NAT يعملان والمشكلة في DNS: المُحلِّل المدفوع، أو حالة المُحلِّل على العميل، أو مجموعة أمان تحجب المُحلِّل. إعدادات DNS في Access Server تقع في منطقة Internet Access نفسها، لكنها تسلك مسار شيفرة مختلفا.

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

لا تدع مربع اختيار يغلق التحقيق

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

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