مصافحة WireGuard تعمل لكن شبكة المكتب الفرعية لا تستجيب

تكتمل المصافحة، wg show ويُبلغ عن نقل حديث، وعنوان النفق على الخادم يستجيب لأمر ping. أما مضيف على الشبكة المحلية للخادم فلا يستجيب. يجب أن تتحقق ثلاثة شروط في الوقت نفسه: على العميل توجيه بادئة الشبكة المحلية إلى النفق، وعلى الخادم إعادة توجيه الحزم، ويحتاج الرد إلى مسار للعودة. وعندما يغيب أحد الثلاثة، تكون العَرَض نفسه.

AllowedIPs قائمة وصول وجدول توجيه في الوقت نفسه

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

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

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

إعادة التوجيه والترجمة مكانهما على الخادم

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

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

عندما انتقلت الشبكة المحلية ولم تنتقل القاعدة

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

iptables -t nat -n -L POSTROUTING
ip -br addr show

قارن المخرَجين. هدف ترجمة لا يظهر في قائمة الواجهات هو العطل، وإصلاحه تغيير من سطر واحد بعد أن تراه. وقد تكون القاعدة في وحدة مُولَّدة لا في إعداد WireGuard، لذا أعد تحميل تلك الوحدة بعد التحرير وتأكد من أن الإقلاع التالي لن يعيد كتابة تغييرك.

موقعان خلف NAT يحتاجان مكانًا يلتقيان فيه

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

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

افصل الطبقات بأربعة فحوص

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

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

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