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

ادفع المسار الافتراضي وتأكد مما ثبّته العميل

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

push "redirect-gateway def1"

بعد إعادة الاتصال، اقرأ جدول توجيه العميل بدلًا من الوثوق بالملف الشخصي. على Linux يظهر إدخالا /1 بجوار المسار الافتراضي الأصلي، ويعرض Windows الزوج نفسه بصيغة 0.0.0.0/1 و128.0.0.0/1. العميل الذي يتجاهل الخيارات المدفوعة، أو الذي ضُبط لرفضها، يحتفظ بمساره الافتراضي القديم ولا يرسل حركة الإنترنت إلى النفق أبدًا. احسم هذه المسألة قبل تغيير أي شيء على الخادم، لأن أي قاعدة على جهة الخادم لا يمكنها التعويض.

التمرير إعداد خادم، لا إعداد VPN

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

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

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

اسمح بالعبور الذي تقصده، ولا شيء غيره

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

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

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

امنح الردود مكانًا تذهب إليه

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

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

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

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

أثبته من العميل، لا من صدفة الخادم

ابدأ بطلب IPv4 رقمي، ثم بحث عن اسم، ثم التطبيق. يثبت ping التمرير والترجمة؛لكنه لا يثبت شيئًا عن تحليل الأسماء، لأن خيارات DNS لا تسري إلا عندما تثبّتها تكاملة العميل.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

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

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