ترجمة عنوان LAN عبر tun0 على بوابة VPN من OpenBSD

غالبًا ما يعطيك مهندسان يتعاملان مع البوابة نفسها من OpenBSD مجموعتين مختلفتين من القواعد للوصول إلى شبكة بعيدة، وكلتاهما قابلة للدفاع. الاختيار بين ترجمة المصدر ومسار العودة ليس مسألة صياغة على الإطلاق. الأمر يتعلق بما يعرفه الطرف البعيد مسبقًا عن 192.168.88.0/24 وبما تحتاج إلى الاحتفاظ به في سجلاتك. أخطئ في ذلك وستبدو قاعدة nat-to صحيحة تمامًا بينما تختفي الردود في البوابة الافتراضية البعيدة.

التوجيه وإعادة الكتابة يجيبان عن سؤالين مختلفين

يقرر جدول التوجيه أن 172.20.0.0/16 يمكن الوصول إليه عبر tun0، ويحدث ذلك القرار قبل الرجوع إلى أي ترجمة pf. ثم تغيّر ترجمة المصدر رأس الحزمة كي يرى الطرف البعيد عنوان النفق الخاص بالبوابة بدلًا من مضيف LAN. لا تحل إحدى الآليتين محل الأخرى: لا تستطيع قاعدة nat أن تخلق مسارًا من العدم، ولا يستطيع مسار أن يقنع موجّهًا بعيدًا لم يسمع قط بشبكتك الفرعية الخاصة. عندما يفتقر الطرف البعيد إلى مسار عودة، تُسقط الردود أو تُمرّر إلى بوابته الافتراضية، ولا يصلح ذلك أي قدر من ضبط القواعد.

ببساطة، التمرير يجيب عن أين تذهب الحركة، والترجمة تجيب عن مَن تبدو الحركة قادمة منه. احتفظ بهما في صندوقين ذهنيين منفصلين أثناء تصميم مجموعة القواعد.

ثلاثة شروط تحسم الأمر

اطرح ثلاثة أسئلة بالترتيب، ويفتح التصميم نفسه عادةً. هل لدى الشبكة البعيدة مسار ثابت يشير إلى عنوان النفق من أجل 192.168.88.0/24، أم يتحكم مسؤولها في الموجّهات على ذلك المسار؟ إن كان الجواب نعم، فدع عناوين LAN تسافر دون تعديل وتخطَّ الترجمة كليًا. هل تحتاج إلى رؤية لكل عميل على الطرف البعيد، سواء لسياسة الوصول أو لأثر تدقيق؟ إن كان الجواب نعم، فالحفاظ على المصدر يستحق عمل التوجيه. هل عنوان النفق مستقر بما يكفي لكتابته في مسار بعيد، أم أنه يتغير بين إعادات الاتصال؟

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

ضع المقتطف حيث يقيمه pf فعلاً

يفترض المقتطف أدناه أن LAN هي 192.168.88.0/24، وأن الشبكة البعيدة هي 172.20.0.0/16، وأن واجهة النفق هي tun0. لا شيء فيه يختار القفزة التالية. إنه يكتفي بإعادة كتابة المصدر في الحزم التي تغادر النفق بالفعل.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

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

لا تنسَ جانب النواة. يجب تمكين تمرير IPv4، ويجب أن تكون قواعد pass ذات الحالة للنفق وشبكة LAN موجودة قبل أن يكون أي من هذا ذا معنى. إن قسم NAT في PF من أسئلة OpenBSD الشائعة هو المرجع الصحيح لترتيب الكلمات المفتاحية هنا.

تحقق من مجموعة القواعد قبل أن تثق بالحركة

افحص الصياغة أولًا بالأمر pfctl -nf /etc/pf.conf، الذي يحلل الملف دون تحميله. ثم حمّل السياسة واقرأ ما تحتفظ به النواة فعليًا، لأن قاعدة حُللت بنظافة قد تظل محجوبة أو مرتبطة بالواجهة الخطأ. يطبع pfctl -sn قواعد الترجمة في صيغتها المحملة، ويطبع pfctl -sr قواعد التصفية بترتيب التقييم.

راقب السلك بعد ذلك. على البوابة، يظهر الأمر tcpdump -ni tun0 'host 172.20.0.10' ما إذا كان عنوان المصدر المغادر للنفق هو عنوان النفق أم مضيف LAN. يؤكد الأمر السريع netstat -rn -f inet الواجهة التي تُحل إليها الوجهة. بمجرد أن تتدفق الحركة، يسرد pfctl -ss سجلات الحالة؛ وإذا لم يُنتج تدفق أي حالة، فلم تطابق الحزمة قط قاعدة تُنشئ واحدة.

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

حين تكلف الترجمة أكثر مما توفر

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

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

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