عنوان VPN مقابل استئجار DHCP في الشبكة المحلية: من يمنح عنوان النفق؟

وصّل العميل وانظر إلى المحوّل بدلًا من أيقونة Wi-Fi. عنوان مثل 10.80.0.14 قد يجلس على نفق بينما لم يسجّل أي خادم DHCP في شبكة المكتب ذلك الاستئجار قط. العملية التي اختارت الرقم هي التي تحدّد من أين يبدأ استكشاف الأخطاء.

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

اقرأ عنوان النفق من جهة العميل

يعرض Windows الفرق إذا قرأت الكتلة كاملة لا السطر الأول. يطبع ipconfig /all وصف المحوّل والعنوان الفيزيائي وسطر DHCP. عادةً يبلّغ محوّل الاتصال الهاتفي PPP أو IKEv2 بأن DHCP معطّل، لأن الاتصال تفاوض على عنوانه أثناء الاتصال بدل استئجاره من خادم في الشبكة المحلية. محوّل النفق الذي يكون DHCP فيه مفعّلًا حالة غير معتادة وتستحق التحقيق بذاتها.

يقسّم Linux المعلومة نفسها بين أداتين. يعطي ip -4 addr show dev tun0 العنوان وطول البادئة. يكشف nmcli -f IP4 connection show work ما إذا جاءت القيمة من ملف تعريف الاتصال أو من تبادل DHCP على الوصلة أو من إعداد مدفوع. WireGuard هو أوضح حالة، لأن wg-quick يطبّق سطر Address من ملف الإعداد عند ظهور الواجهة، ولا يمنح أي نظير شيئًا وقت الاتصال.

البادئة تخبرك بشيء أيضًا. يعني /32، أو قناع 255.255.255.255، أن البوابة تتوقع التوجيه إلى عنوان مضيف واحد، بينما يشير قناع أوسع إلى شبكة فرعية على الوصلة في مكان ما خلف النفق.

ما تحمله حمولة إعداد IKEv2

لـ IKEv2 آلية مخصّصة لهذه المهمة. تحمل حمولة الإعداد الموصوفة في RFC 7296، القسم 3.15.1 سمات مثل INTERNAL_IP4_ADDRESS، INTERNAL_IP4_NETMASK، INTERNAL_IP4_DNS ونظيراتها من IPv6. يرسل العميل سمة بقيمة بطول صفر عندما لا يكون لديه تفضيل، ويعيد المستجيب القيمة التي يريد استخدامها. يجري ذلك التبادل داخل IKE_AUTH، مشفَّرًا أصلًا، فلا يعبر أي بث DHCP النفق أبدًا.

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

سمة قناع الشبكة اختيارية عمليًا. كثير من عمليات النشر تعيد عنوانًا فقط وتترك العميل يثبّت مسار مضيف، ولهذا قد يبدو المجمّع نفسه /32 على عميل، ثم /24 على آخر.

حيث يتصادم نطاق DHCP المحلي ومجمّع VPN

تبدأ المشكلة عندما يشير المانحان إلى النطاق نفسه. خادم DHCP لـ 10.20.30.0/24 لا يعرف شيئًا عن مجمّع VPN مهيّأ لـ 10.20.30.128/25، فلا شيء يمنعه من استئجار 10.20.30.140 لطابعة بينما تمنح البوابة العنوان نفسه لعميل بعيد. يبقى التصادم صامتًا أيامًا ثم يظهر كتكرار متقطّع.

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

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

تحقّق من العملية التي تملك العنوان

أثبت الملكية قبل تغيير أي نطاق. على العميل، سجّل العنوان والبادئة. على الشبكة المحلية، ابحث في قاعدة بيانات الاستئجار. على البوابة، اسرد المجمّعات التي أُعدّت لتوزيعها. العنوان الموجود في ملف الاستئجار يخص خادم DHCP، أي أن النفق مجسور أو مُمرَّر؛ والعنوان الموجود في مجمّع البوابة وحده يخص نقطة نهاية النفق.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

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

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