مصافحة WireGuard تعمل لكن لا إنترنت: تتبّع الحزمة
المصافحة لا تثبت إلا المفاتيح وإمكانية الوصول. تتبّع حزمة واحدة من AllowedIPs عبر التمرير وNAT ومسار العودة لترى أين تتوقف.
النفق قائم، ويُبلّغ wg show عن مصافحة حديثة، وتستطيع تنفيذ ping لعنوان النفق على الخادم، ولا شيء بعده يستجيب. الغريزة هي إعادة توليد المفاتيح أو إعادة مشاركة الإعداد. وهذا يغيّر الجزء الوحيد من المسار الذي أُثبت بالفعل أنه يعمل.
المصافحة المكتملة تقول إن الطرفين متفقان على المفاتيح، وإن UDP يصل إلى نقطة النهاية، وإن التوجيه بالتشفير يقبل الحزمة. وهي لا تقول شيئًا عن قدرة الحزمة على مغادرة الخادم بعد ذلك.
لذلك تتبّع حزمة واحدة بدلًا من التخمين. هناك أربعة مواضع يمكن أن تموت فيها الحزمة، وكل موضع يترك أثرًا مختلفًا.
ما الذي تثبته المصافحة فعليًا
WireGuard بروتوكول UDP ينشئ جلسة بمصافحة Noise ثم يشفّر الحزم لطرف مقابل. وعندما يسرد wg show مصافحة عمرها بضع ثوانٍ وعدّاد نقل متزايدًا، تكون نقطة النهاية والمفاتيح والمفتاح العام للطرف المقابل صحيحة كلها.
ما لا تثبته هو أن عميلك يرسل حركة المرور المتجهة إلى الإنترنت إلى الواجهة أصلًا، أو أن الخادم مستعد لتمريرها، أو أن الرد يستطيع أن يجد طريقه عائدًا. هذه قرارات توجيه في النواة وقرارات جدار ناري، وتُتخذ خارج النفق.
لهذا فإن تنفيذ ping لعنوان النفق على الخادم اختبار مضلّل إلى هذا الحد. تلك الحزمة موجّهة إلى الخادم نفسه، لذا تنتهي محليًا. وهي لا تحتاج إلى تمرير قط، ولا إلى ترجمة قط، ولا إلى مسار عودة من الإنترنت.
AllowedIPs قرار توجيه
على العميل، يؤدي AllowedIPs مهمتين. فهو جدول التوجيه بمفتاح التشفير الذي يقرّر عناوين الوجهة التي تُرسل إلى نفق هذا الطرف المقابل، وهو قائمة عناوين المصدر التي سيقبلها الطرف المقابل منك. وإذا لم يسرد إعداد العميل سوى 10.8.0.0/24، فلا تدخل وجهات عامة الواجهة أبدًا ويحملها مسارك الافتراضي المعتاد خارج النفق. حينها يعمل النفق بشكل مثالي ولا يفعل شيئًا مما أردت.
انظر إلى ما ثبّته العميل فعليًا بدلًا مما يقوله ملف الإعداد:
wg show wg0 allowed-ipsip route get 1.1.1.1
الأمر الثاني هو الأمر الحاسم. إذا كان الجواب يذكر واجهتك الفعلية والبوابة المعتادة، فالحزمة لا تمر عبر النفق ولن يصلحها أي تغيير على جانب الخادم. أضف 0.0.0.0/0 لعنوان IPv4 و ::/0 لعنوان IPv6 كلًا على حدة؛ فالتغطية الشاملة لعائلة واحدة تترك الأخرى على مسارها الأصلي، وهذا سبب شائع لنفق IPv4 عامل وبحث IPv6 متوقف.
أين تموت الحزمة على البوابة
إذا كان المسار صحيحًا والحزمة ما زالت لا تذهب إلى أي مكان، فهي تصل إلى الخادم وتتوقف هناك. أربعة فحوص تغطي معظم البوابات.
التمرير. sysctl net.ipv4.ip_forward إذا أرجع 0 فهذا هو الجواب الكلاسيكي، وكثير من التوزيعات ما زالت على 0 افتراضيًا. ويجب أن يكون 1، ويُضبط بشكل دائم في ملف sysctl بدلًا من أمر يختفي عند إعادة التشغيل. تمرير IPv6 مفتاح منفصل.
سياسة التصفية. سلسلة FORWARD بسياسة إسقاط افتراضية ستهمل حركة المرور الممرّرة في النفق بينما تسمح بالمرور إلى المضيف نفسه، وهذا يطابق العَرَض تمامًا. اقرأ مجموعة القواعد الحيّة لا ملفًا محفوظًا: nft list ruleset أو iptables -S.
الترجمة أو التوجيه. يحتاج العملاء الذين يستخدمون عناوين نفق خاصة إما إلى NAT مصدر على واجهة خروج الخادم أو إلى بادئة موجّهة تعرف الشبكة الأعلى كيف تعيدها. والاختيار بينهما يتبع خطة العناوين. وإضافة MASQUERADE إلى شبكة تعيد توجيه بادئتك بالفعل غير ضارة لكنها بلا فائدة، وإغفالها حيث لا يوجد مسار يترك الردود موجّهة إلى نطاق خاص غير قابل للتوجيه.
مسار العودة. في التصاميم الموجّهة، يحتاج الموجّه الأعلى إلى مسار يشير إلى خادمك. وقد تحجبه شبكة المزوّد أيضًا: عدة سحابات تفعّل فحص المصدر والوجهة على المثيل، فيُسقط بصمت الحزم التي ليس مصدرها عنوان المثيل نفسه إلى أن يُعطّل ذلك الفحص.
DNS يفشل بشكل مختلف عن التوجيه
الحزمة إلى عنوان معروف وبحث الاسم فشلان منفصلان، ورسائل الخطأ تضلّل في اتجاهين متعاكسين. إذا نجح ping 1.1.1.1 ولم يستطع المتصفح تحميل أي شيء، فالمسار سليم واسم النطاق ليس كذلك. وإذا فشل الـ ping نفسه، فـ DNS غير ذي صلة وقد عدت إلى القسم السابق.
يستطيع wg-quick ضبط مُحلّل من سطر DNS = في الإعداد، وsystemd-resolved له سلوكه الخاص لكل رابط. وأي VPN يستبدل المُحلّل بعنوان لا يُبلغ إلا داخل النفق سيفشل في كل بحث لحظة سقوط النفق، وهو ما يبدو كأن النفق يعطّل الإنترنت.
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
ترتيب يُنتج أدلة
نفّذ فحص جانب العميل أولًا، لأنه أمر واحد ويستبعد نصف الاحتمالات. ثم تأكد من أن الخادم مخصص أصلًا ليكون مخرجًا إلى الإنترنت؛ فالبوابة المبنية للوصول الخاص ليست معطوبة عندما تفشل الوجهات العامة.
على الخادم، راقب الواجهة أثناء إرسال ping من العميل: يجب أن يُظهر tcpdump -ni wg0 icmp الطلب، ويجب أن يُظهر tcpdump -ni eth0 icmp خروجه، مترجَمًا أو غير مترجَم. وإذا ظهر على الأول ولم يظهر أبدًا على الثاني، فالتوقف محلي على الخادم. وإذا خرج ولم يعُد أي رد، فالمشكلة في الأعلى، وذلك حديث آخر.
أخيرًا اجعل الإصلاح يصمد أمام إعادة التشغيل. التمرير مكانه ملف sysctl، وقواعد جدار الناري مكانها الخدمة التي تحمّلها، ومسارات العميل مكانها الإعداد الذي يرفع الواجهة لا صدفة سوف تنساها. أعد الاتصال، وكرر الاختبارين نفسهما، وأكّد أن العدّادات تتحرك.