عميل VPN موجَّه يصل إلى الخادم لكن لا يصل إلى مضيفي الشبكة المحلية

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

اتبع الرد، لا الطلب

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

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

ضع مسار العودة حيث تنظر المضيفات

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

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

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

لماذا يبدو NAT المصدر كأنه يصلح الأمر

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

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

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

مسار السحابة يحتاج إلى ثلاثة إعدادات

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

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

نفّذ الفحوص بهذا الترتيب

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

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

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

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