لماذا يتعذّر الوصول إلى عملاء Access Server من الشبكة المحلية

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

اقرأ عنوان المصدر الذي تراه الخدمة

هذا الحقل الواحد يحدد كل ما تبقى. إذا رأت الخدمة الداخلية عنوان التجمع، فخادم Access Server يوجّه حركة العملاء بدل إخفائها، وكل رد يجب أن يُوجَّه عائدًا إلى التجمع. وإذا رأت عنوان الخادم الخاص نفسه بدلًا من ذلك، فالخادم يقوم بالتمويه ولا يزال مسار الرد يعمل، لكن على حساب فقدان هوية كل عميل في سجلات الخدمة وقواعد الوصول.

قارن الطرفين قبل تغيير أي شيء. على الخادم، اسرد واجهات النفق وعناوينها؛ وعلى العميل، تأكد من أي تلك العناوين يحمله فعلًا؛ وعلى المضيف الداخلي، انظر إلى اتصال جارٍ.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

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

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

أضف المسار حيث يُحسم الرد

المسار ملك للبوابة التي تستخدمها الخدمة الداخلية أصلًا، لا للخدمة، إلا إذا كانت توجّه حركتها بنفسها. وجّهه إلى العنوان الخاص القابل للوصول الخاص بخادم Access Server، وهو قيمة مختلفة عن عنوان النفق الذي يحمله العميل.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

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

اجعل المسار دائمًا، وحافظ على دقة أحجام التجمعات. التجمعان غير المتجاورين يحتاجان مسارين، والتجمع الذي يكبر خارج بادئته المضبوطة ينتج بصمت عملاء لا تجد ردودهم مكانًا تذهب إليه. وإذا كانت نطاقات التجمعات تحت سيطرتك، فاختر ملخّصًا يمكنك توجيهه مرة واحدة وتركه.

يجب أن يتفق التمرير والمرشحات مع المسار

التوجيه نصف المسار فقط. يجب أن يُسمح للخادم بالتمرير بين النفق والواجهة الخاصة، وهذا يعني على لينكس net.ipv4.ip_forward مع سلسلة تمرير تسمح بزوج الواجهات، وعلى مضيف مُحصَّن عادةً قاعدة صريحة لكل اتجاه.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

الترشيح ذو الحالة يفسر عرضًا يقود الناس إلى الطريق الخطأ. لا يحتاج الرد داخل تدفق قائم إلى قاعدة واردة جديدة، لذا فالاتصال الذي يتعلق بعد SYN-ACK لا يُحجب بسبب قاعدة قبول مفقودة؛ بل يُسقَط أو يُوجَّه خطأً. احتفظ بهذا التمييز، لأنه يفصل تغيير التوجيه عن تغيير جدار الحماية.

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

موجَّه أو مموَّه: اختر بوعي

يحافظ الوضع الموجَّه على عنوان تجمع العميل عند الخدمة، ما يجعل التسجيل لكل عميل والسياسة لكل عميل ممكنين، وفي المقابل يحتاج كل شبكة داخلية يجب أن تجيب عميلًا إلى مسار التجمع. ويزيل الوضع المموَّه هذا الشرط لأن الردود تعود إلى الخادم، لكن الخدمة لم تعد تميّز عميلًا من آخر ولا تستطيع بدء أي شيء نحو عميل بعينه.

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

الشبكة الفرعية خلف العميل مهمة منفصلة

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

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

تحقق بتدفق واحد والتقاط واحد

أثبت المسار باتصال واحد بدل اختبار وصول عام. راقب التدفق نفسه عند الطرفين: الطلب الواصل إلى الخدمة والرد المغادر لها.

tcpdump -ni any host 10.90.0.25 and port 443

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

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