الوصول إلى شبكة /24 بعيدة عبر نفق: NETMAP أم DNAT أم التوجيه؟
اربط بادئة كاملة بـ NETMAP، أو أضف قواعد DNAT لكل مضيف، أو وجّه النطاق الحقيقي، ثم قرّر بحسب ما يجب أن يراه الطرف البعيد ومن يجوز له بدء حركة المرور.
يمكنك الوصول إلى شبكة فرعية خلف نقطة نفق بثلاث طرق، وجمع الحقائق لدقيقة واحدة عادةً يستبعد طريقتين. الحقائق هي: هل يجب أن يميّز الخوادم هناك بين المستخدمين، وهل سيصدر من هناك اتصال نحو نطاقك يومًا، ومن يجوز له تعديل موجّه الطرف البعيد. أجب عن هذه الثلاثة فيختار التصميم نفسه. بقية النص تفترض أنك تدير نقطة النفق ويجوز لك تعديل جدار الحماية الخاص بها.
ثلاثة خيارات، وما يغيّره كل منها فعلاً
ربط البادئات وDNAT لكل مضيف وبادئة موجّهة تنقل كلها الحزم بين النطاقين نفسهما، لكنها تغيّر أشياء مختلفة. الربط يبتكر نطاقًا بديلًا ويعيد كتابة العناوين حسابيًا أثناء المرور. قواعد لكل مضيف تعيد الكتابة أيضًا، إلا أن كل وجهة تُسمّى يدويًا. البادئة الموجّهة لا تعيد كتابة شيء: تحتفظ الحزم بالعناوين الحقيقية ويتفق الطرفان على مكان تلك العناوين.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
ابدأ الاستبعاد من الطرف البعيد، حيث القيود أصعب في التغيير. إذا كان خادم هناك يكتب عناوين العملاء في السجلات، أو يفحصها مقابل قائمة سماح، أو يسلّمها لنظام آخر، فإن ترجمة المصدر تدمّر معرّفه الوحيد. وإذا كان على الطرف البعيد أن يتصل هو أيضًا، فالترجمة مستبعدة تمامًا، لأن لا شيء هناك يعرف بوجود النطاق البديل. فقط حين يقتصر الطرف البعيد على الرد على الطلبات تصبح الخيارات الأرخص آمنة.
أزواج البادئات، ولماذا يجب أن تتساوى الأحجام
NETMAP هدف في جدول nat يعمل على زوج من البادئات متساوية الطول. لا يحوي جدولاً لكل عنوان: يجرّد البادئة، ويحتفظ ببتات المضيف ويعيد إلحاقها بالبادئة الجديدة، ولهذا تُربط /24 بـ /24 ولا تُربط أبدًا بـ /25. الموضع يحدد الاتجاه: مطابقة الوجهة في PREROUTING تعيد كتابة وجهة الحزمة، ومطابقة المصدر في POSTROUTING تعيد كتابة مصدرها.
يظهر المضيف 192.168.2.17 لعملائك كـ 10.50.1.17، والثماني الأخير ليس زينة — إنه الرقم نفسه على الجانبين. أضف غدًا مضيفًا عند 192.168.2.40 وسيكون بديله 10.50.1.40، دون أي قاعدة تُعدّل.
لا يزال العملاء بحاجة إلى مسار لنطاق البديل يشير إلى جهازك، إلا إذا كان البديل داخل شبكة فرعية يصلونها أصلاً. ولا يحتاج البوابة إلى مسار للبديل، لأن ترجمة الوجهة تجري في PREROUTING قبل البحث في جدول التوجيه. ويجب تفعيل تمرير الحزم أيضًا، وإلا أسقطت النواة الحزمة بعد إعادة الكتابة. الأوامر الثلاثة أدناه هي الإعداد كله على بوابة من طراز Debian مع العملاء على br0 والبديل على 10.50.1.0/24 والنفق على tun0.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEعلى الرد أن يجد طريق عودته بنفسه
إعادة كتابة الوجهة تحدد فقط أين تُسلَّم الحزمة. ولا يزال على خادم الطرف البعيد أن يرد على عنوان يستطيع الوصول إليه، وهناك طريقتان لترتيب ذلك. ترجم المصدر لتعود الردود إلى جهازك، أو اترك المصدر كما هو وامنح الطرف البعيد مسارًا لنطاق العملاء.
التمويه عند الخروج هو الطريق الأقصر: قاعدة واحدة في POSTROUTING ويرى الطرف البعيد عنوان نفقك، فلا يحتاج إلى مسار خاص به. الثمن هو أن كل المستخدمين ينهارون في عنوان واحد، فتتوقف السجلات لكل مستخدم عن معنى. إبقاء المصدر سليمًا يحفظ تلك المعلومة، لكن على الموقع البعيد حينها أن يرسل ردود نطاق العملاء عبر النفق. على خادم OpenVPN يُدفع إليه push "route 10.50.9.0 255.255.255.0"، إلى جانب سطر route 192.168.2.0 255.255.255.0.
الفشل المكلف هو تنفيذ نصف كل نهج. إذا موّهت بعض الحركة بينما يحمل الطرف البعيد أيضًا مسار عودة لحركة أخرى، تصل الردود على واجهة لم يُر فيها إدخال تتبع الاتصال قط. ويبلّغ العميل عن انتهاء المهلة لطلب سجّل الخادم أنه خُدم. يجب أن يعبر اتجاهَا التدفق نفس نسخة netfilter: بوابة واحدة تترجم، لا جدارا حماية على التوالي.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nاقرأ الإدخال في الاتجاهين: تحتفظ المجموعة الأصلية ببديلك في الوجهة، بينما تحمل مجموعة الرد العنوان الحقيقي. إذا غابت مجموعة الرد، فالمشكلة في مسار العودة لا في القاعدة. وإذا لم تتحرك عدادات PREROUTING أبدًا، فالحزمة لم تصل إلى ذلك الخطاف قط.
التعارضات والبحث الذي يجري أولاً
يمكن أن يتعارض نطاقان مختلفان، وكلا الفشلين يبدو كنفق معطوب لا كقاعدة سيئة. البديل الذي تبتكره يجب أن يكون غير مستخدم على طول المسار كله، ويجب ألا يكون نطاق الطرف البعيد الحقيقي موجودًا أصلاً على شبكتك. التكرار ينتج حركة متقطعة إلى المضيف الخطأ، وتشخيصها أصعب من اتصال مرفوض. اسأل جدول التوجيه قبل أن تضيف قاعدة.
على البوابة، يجب أن يسمّي ip route get 192.168.2.17 جهاز النفق؛ وجود جسر محلي يعني أن النطاق البعيد محجوب ولن تصلحه أي قاعدة nat. إذا كانت شبكتك تستخدم 192.168.2.0/24 بالفعل، فأعد ترقيم الموقع البعيد بدلًا من تكديس ربط فوق التعارض.
اختباره من عميل حقيقي، ثم الحفاظ عليه
اختبر من جهاز سيستخدم البديل فعلاً، لا من البوابة، لأن الحركة المولّدة محليًا لا تعبر PREROUTING بالطريقة نفسها أبدًا. افتح اتصالًا بمضيف واحد له بديل وراقب ظهور العدادات وإدخال conntrack معًا، ثم أغلقه وتأكد من مغادرة الإدخال. الإدخال القديم يشير إلى اتصال نصف مفتوح، وهذا يعني عادةً أن الرد لم يعد قط.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17اتصالان أو ثلاثة ناجحة تثبت الحساب، لكنها لا تقول شيئًا عن الاستمرارية ولا عن المهندس التالي. احفظ القواعد حيث يقرأها إقلاع النظام، وهذا على Debian وUbuntu يعني iptables-save > /etc/iptables/rules.v4 مع تفعيل netfilter-persistent. الربط الذي يزول عند إعادة التشغيل أسوأ من عدمه، لأن الانقطاع يأتي دون تغيير حديث يُلام.
اترك ملاحظة بجانب القواعد: نطاق البديل، والنطاق الحقيقي، وسبب الزوج، وأي جانب يجوز له البدء. تلك الملاحظة تفصل تصميمًا عن كومة قواعد لا يجرؤ أحد على حذفها. وهي تحسم أيضًا السؤال اللاحق، حين يضيف الموقع البعيد مضيفًا فيجيب عنوان لم يضبطه أحد. إذا قالت الملاحظة إن الطرف البعيد يحتاج مسار عودة، عرف الشخص التالي أن إزالة قاعدة التمويه تقطع الاتصال. التوثيق هنا رخيص؛ أما إعادة اكتشاف اعتماد على NAT في الثالثة صباحًا فليست كذلك.