عملاء الشبكة السفلى خلف VPN علوي: توجيه أم NAT؟

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

حدّد نموذج الإعادة قبل أن تلمس التوجيه

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

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

اختر صفًا واحدًا والتزم به. الصفان بديلان لا خطوتان، وخلطهما ينتج تصميمًا لا يستطيع أحد شرحه عند المراجعة.

الحفاظ على المصدر عبر التوجيه

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

إذا كانت الإجابة نعم، فالإعداد المحلي صغير: تمكين إعادة التوجيه، وقائمة allowed-ips لنظير WireGuard تغطي نطاق الشبكة السفلى، وسياسة جدار ناري تسمح بالعبور في الاتجاهين.

ترجمة المصدر المتعمّدة

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

يحتاج IPv6 إلى تصميم خاص به؛ ونسخ سطر masquerade الخاص بـ IPv4 ليس معمارية. اختبر المسار المترجم باتصال جديد لا باتصال مخزّن مؤقتًا.

مسار البيانات المحلي ما زال عليه أن يعمل

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

اختبر من جهاز سفلي فعلي، لا من البوابة. عنوان المصدر هو جوهر التمرين كله.

مصدر واحد يعني هوية جلسة واحدة

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

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

حدّد حالة الانقطاع ثم اختبر ثلاثة طلبات

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

سجّل التراجع في سطر واحد لكل قاعدة، حتى يمكن إلغاء التغيير دون إعادة بناء النية.