عملاء VPN يصلون إلى الخادم لا إلى شبكة LAN: أي حل؟

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

أولًا، تأكد من الاتجاه المعطل

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

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

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

السؤال الأول: هل يمكنك تعديل موجّه شبكة LAN البعيدة؟

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

يفشل بصمت في اليوم الذي يغير فيه أحدهم المجمع. اكتب القيمة مرة واحدة واعتبر أي تعديل في أحد المواضع الثلاثة تعديلًا في الثلاثة.

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

السؤال الثاني: هل يمكن لشبكة LAN أن تتوقف عن رؤية عناوين العملاء؟

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

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

الثمن هو الإسناد: تختفي عناوين كل عميل من سجلات شبكة LAN. عندها يجب أن تسمي أي قائمة سماح على مضيف شبكة LAN الخادم بدلًا من المجمع.

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

السؤال الثالث: هل الخادم نفسه عميل لنفق آخر؟

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

ثم تحقق من الاتجاهين ومن الحجمين

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

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

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