عميلا VPN، عنوانان عامّان: اجعل SNAT متوافقاً

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

أي هوية تصل إلى البوابة

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

iptables -t nat -S POSTROUTING

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

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

الترجمة لا تستطيع اختراع عنوان

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

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

أدرج قبل masquerade العام

تأكد من واجهة الخروج والسلسلة الحالية قبل إضافة أي شيء. الأول يحدد الحزم التي يمكن للقاعدة مطابقتها، والثاني يُظهر ما يقف بالفعل أمامها.

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

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

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

تطابق القاعدتان أعلاه عنواناً داخلياً واحداً لكل منهما، وتقصران المطابقة على واجهة الخروج، وتضبطان المصدر صراحةً. أدرج بدلاً من أن تُلحق: عند الموضع 1 تُقيَّمان قبل سطر masquerade. الترتيب بينهما لا يهم لأن مصدريهما مختلفان. استبدل ens3 بما أفاد به أمر المسار، وأبقِ مديري الجدران النارية الآخرين بعيداً عن الخطافات نفسها، لأن أداتين تكتبان جدولاً واحداً هو السبب المعتاد في أن قاعدة صحيحة لا أثر لها.

أثبت المصدر بتدفق جديد

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

conntrack -L -s 10.88.4.20 -p tcp --dport 443

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

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