SNAT مقابل DNAT مقابل Masquerade: ماذا تفعل كل قاعدة NAT في VPN

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

ماذا تعيد كل قاعدة كتابته

ترجمة المصدر NAT، وتُكتب عادة SNAT، تغيّر عنوان المصدر لتدفق عند خروجه من موجّه أو بوابة. تردّ الخدمة المستقبِلة على العنوان المترجَم، ويعكس الجهاز الذي يترجم التغيير باستخدام الحالة التي احتفظ بها لذلك الاتصال. على Linux تعيش تلك الحالة في conntrack، ولهذا يطبع conntrack -L الصفوف الأصلية وصفوف الرد جنبًا إلى جنب.

ترجمة الوجهة NAT، أي DNAT، تغيّر الوجهة بدلًا من ذلك. يمكن إعادة كتابة حزمة موجّهة إلى عنوان عام على UDP 51820 لتصل إلى خادم WireGuard داخلي على 10.8.0.2:51820. هكذا ينشر موجّه منزلي أو موازن حمل سحابي مستمع VPN، وهذا لا يقول شيئًا عمّا قد يحمله النفق بعد ذلك.

تنتمي Masquerade إلى عائلة SNAT. لا تسمّي القاعدة أي عنوان؛ بل تستخدم أي عنوان تحمله الواجهة الصادرة عند مغادرة الحزمة. يمنحها Linux هدفًا خاصًا بها، وهي الخيار المعتاد على واجهة WAN تحصل على عنوانها من DHCP أو PPPoE.

مكان وجود الخريطة يحدّد نوع الفشل

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

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

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

Masquerade أم SNAT صريحة

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

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

هنا يعضّ IPsec القائم على السياسة بأقصى قوة. يشرح دليل إعادة التمرير في strongSwan كيفية تمكين إعادة تمرير IP وإضافة قاعدة SNAT للعملاء، وتغطي الوثائق نفسها استبعاد الحركة التي يجب أن تحتفظ بعنوانها الأصلي. ترجم مصدرًا قبل أن تطابقه السياسة الأمنية، وقد يرتفع النفق بينما تظل الحركة تسقط، لأن الحزمة لم تعد تشبه المحدِّد الذي جرى التفاوض عليه.

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

قراءة القواعد على بوابة Linux

بوابة وصول عن بُعد لديها عملاء على 10.8.0.0/24 وواجهة WAN باسم eth0 تحتاج إلى تمكين إعادة التمرير وإلى سياسة تصفية تسمح بالتدفق قبل أن تساعد أي قاعدة NAT. تحتفظ نسخة iptables بالاتجاهين في جدول nat:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

تستخدم صيغة nftables الخطّافين نفسيهما مع واجهة مسمّاة وسلسلة صريحة:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

تفترض المقطوعتان أن سلسلة التصفية تقبل بالفعل التدفق المعاد تمريره. قاعدة NAT ليست قاعدة سماح، وحزمة مترجمة بشكل صحيح قد تُسقَط بعد جدول واحد. أكّد الخريطة الحية باستخدام conntrack -L، وأكّد ما هو محمّل باستخدام nft list ruleset أو iptables-save -t nat، ثم التقط على الواجهتين لترى العنوان يتغيّر فعليًا.

أنماط فشل تبدو كقاعدة سيئة

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

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

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

قائمة تحقق قبل حفظ القاعدة

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

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