المشكلة: إدارة عشرة أنفاق WireGuard يدوياً
WireGuard ممتاز من الناحية التقنية، لكن نموذج إعداده ثابت: كل نظير يجب أن يعرف IP العام ومفتاح كل أقرانه. في بيئة تضم عشرة عملاء مع أجهزة متنقلة ومكاتب خلف CGNAT وخوادم ذات IP متغير، تقضي وقتاً أطول في مزامنة ملفات wg0.conf بدلاً من العمل المنتج. أضف خادم VPS → عدّل قائمة الأقران على تسعة أجهزة. أزل تقنياً → ألغِ مفتاحه في كل مكان. تغيرت الشبكة الفرعية؟ ابدأ من جديد. هذا هو الكابوس التشغيلي الذي صُمم NetBird للقضاء عليه.
- Mesh تلقائي: NetBird يدير مستوى التحكم — كل نظير جديد يُعلن عن نفسه والآخرون يكتشفونه تلقائياً.
- اجتياز NAT وCGNAT: يستخدم NetBird بروتوكول STUN لإنشاء اتصالات مباشرة عبر شبكات NAT المنزلية والمؤسسية.
- تمرير TURN تلقائي: عند استحالة الاتصال المباشر، يتحول NetBird بصمت إلى مُرحِّل مشفر.
- تدقيق وصول دقيق: سياسات التحكم في الوصول تحدد أي الأقران يمكنه الوصول إلى أي خدمة.
- مفتوح المصدر (BSD-3 للعميل، AGPLv3 للخادم): لا قيود على البائع، إمكانية الاستضافة الذاتية.
المتطلبات الأساسية
قبل تثبيت NetBird، تحقق من استيفاء بنيتك التحتية للمتطلبات التالية.
- خادم VPS ServOrbit يعمل بنظام Ubuntu 22.04/24.04 أو Debian 12 مع صلاحية root.
- حساب NetBird Cloud (مجاني حتى 5 أقران) أو مستوى تحكم ذاتي الاستضافة.
- المنافذ الصادرة 443 (HTTPS/WSS) و3478 (STUN/UDP) غير محجوبة من الخادم.
- ميزة Peer Expose مفعّلة في حسابك (متاحة في خطط Team وما فوق).
ربط خادم VPS ServOrbit بشبكة NetBird
إليك الإجراء الكامل لتوصيل خادم VPS ServOrbit بشبكة NetBird mesh.
تثبيت عميل NetBird
على الخادم، أضف المستودع الرسمي وثبّت الحزمة:
curl -fsSL https://pkgs.netbird.io/install.sh | sh
تحقق من الإصدار: netbird version يجب أن يعرض 0.76.x.إنشاء مفتاح إعداد
في لوحة تحكم NetBird، انتقل إلى Setup Keys وأنشئ مفتاحاً. انسخه — لن يُعرض إلا مرة واحدة.
ربط النظير بمستوى التحكم
على الخادم:
netbird up --setup-key <YOUR_SETUP_KEY>
يظهر النظير في لوحة التحكم في غضون ثوانٍ.إضافة النظير إلى مجموعة الشبكة
في واجهة NetBird، انتقل إلى Peers، اختر الخادم الجديد وأضفه إلى المجموعة المطلوبة. تُطبَّق سياسات الوصول فوراً.
التحقق من اتصالية الـ mesh
من نظير آخر في الشبكة:
netbird statusثمping 100.x.x.x
استجابة ping تؤكد نجاح النفق.
أمر `netbird expose`: خدمة داخلية بدون منفذ عام
يتيح أمر netbird expose عرض خدمة تعمل محلياً عبر Reverse Proxy الخاص بـ NetBird — دون فتح أي منفذ على جدار حماية الخادم. الخدمة مؤقتة وتختفي عند إيقاف الأمر.
مثال عملي: لوحة مراقبتك تعمل على localhost:3000 وتريد إتاحتها فقط لأعضاء موثوقين:netbird expose --protocol http --local-address localhost:3000 --with-user-groups supervision-admins
يُنشئ NetBird رابطاً عاماً في *.tunnel.netbird.io. المنفذ 3000 يبقى مغلقاً تماماً على مستوى جدار الحماية.
للوصول المحمي بكلمة مرور دون SSO، أضف --with-password: يعرض NetBird كلمة مرور عشوائية تشاركها مع زملائك. مفيد للوصول الطارئ لعميل ليس لديه حساب في مستأجر NetBird الخاص بك.
حالة استخدام الوكالة: ربط VPS العميل والمكتب وجهاز المسؤول
البنية المقترحة لوكالة تدير عشرة عملاء مستقلين: أنشئ مجموعة لكل عميل. خادم كل عميل ينتمي لمجموعته. أجهزة المسؤولين تنتمي فقط لمجموعة عميلهم. مكتب الوكالة في مجموعة agency-ops لها وصول لجميع مجموعات العملاء.
للاتصال بخادم العميل عبر SSH دون منفذ عام:ufw allow in on netbird0 to any port 22 ثم ufw deny 22
مرّر الجدول أفقيًا
| المعيار | NetBird 0.76 | Tailscale | WireGuard يدوي |
|---|---|---|---|
| إدارة الأقران | تلقائية (مستوى تحكم مركزي) | تلقائية (سحابة Tailscale) | يدوية (ملفات wg0.conf على كل عقدة) |
| اجتياز NAT/CGNAT | STUN + TURN تلقائي | STUN + DERP تلقائي | يتطلب IP عاماً أو port-forward |
| نموذج التسعير | مجاني حتى 5 أقران؛ خطط مدفوعة؛ استضافة ذاتية مجانية | مجاني حتى 3 مستخدمين؛ خطط مدفوعة | مجاني (برنامج)، تكلفة تشغيلية بالوقت |
| مفتوح المصدر | نعم (BSD-3 عميل، AGPLv3 خادم) | العميل مفتوح (BSD-3)، الخادم خاص | نعم (GPLv2 kernel، MIT userland) |
| عرض خدمة بدون منفذ مفتوح | نعم (`netbird expose`) | لا (Funnel متاح لكن مختلف) | لا (نفق SSH يدوي) |
| تدقيق وسياسات وصول | واجهة ويب كاملة، مجموعات وسياسات | ACL عبر ملف HuJSON، واجهة ويب | لا شيء — AllowedIPs فقط لكل نظير |
استكشاف الأخطاء: 3 مشاكل شائعة
1. نظير غير قابل للوصول — شغّل netbird status --detail لفحص حالة ICE. تحقق من أن المنفذ 3478/UDP الصادر مفتوح.
2. STUN/TURN محجوب بجدار حماية مؤسسي — NetBird يدعم TURN على TCP/443. فعّل Force TCP في لوحة التحكم.
3. قراءة السجلات — على لينكس مع systemd:journalctl -u netbird -f --since '5 minutes ago'
استكشاف الأخطاء: وكيل NetBird يبقى عالقاً عند `Issuing certificate…`
منذ أن بدأ NetBird بتقديم وكيله العكسي ذاتي الاستضافة، يتكرر عَرَض واحد في سجل البلاغات: الخدمة التي أُنشئت في لوحة التحكم تبقى إلى أجل غير مسمى عند Issuing certificate… ولا يمكن الوصول إليها أبداً. البلاغ netbird #5517 الذي فُتح في 5 مارس 2026 وظل مفتوحاً عند آخر نشاط له في 19 أكتوبر 2026 يضم 35 تعليقاً. وغالباً ما يعرض سجل الوكيل هذه الرسالة: acme/autocert: unable to satisfy "https://acme-v02.api.letsencrypt.org/acme/authz/…" for domain "subdomain.site.tld": no viable challenge type found. تقول الرسالة إن جهة إصدار الشهادات لم تتلقَّ أي إجابة صالحة عن تحدياتها، ولا تقول السبب. لذلك لا يوجد سبب واحد: يصف المشاركون عدة أسباب، ولم يؤكد فريق NetBird سوى سبب واحد منها. فيما يلي ترتيب للتشخيص يستبعد الأسباب واحداً تلو الآخر.
قراءة سجل الوكيل
شغّل
docker compose logs proxy | grep -i acme: تشير وثائق NetBird إلى هذا الأمر للخدمات العالقة في الحالة certificate_pending أو التي انتقلت إلى certificate_failed. دوّن نص الخطأ بدقة قبل تغيير أي شيء، لأن permission denied وno viable challenge type found لا يشتركان في العلاج نفسه.فحص صلاحيات مجلد الشهادات
خطأ من نوع
open /certs/acme_account+key…: permission denied هو الحالة الوحيدة التي حسمها أحد المتعاونين في المستودع: فقد أجاب بأن أي تحديث لن يصلحها وأن المشكلة في الصلاحيات. ويذكر مشارك أنه عالجها بإسناد مجلد certs إلى المستخدم 1000:1000 (chown 1000:1000) وبربط مجلد فارغ على /var/lib/netbird. هذا حل مُبلَّغ عنه لتثبيته الخاص: تحقق من المستخدم الذي تعمل به حاويتك قبل نسخه.التحقق من DNS وسجلات CAA والمنافذ
يجب أن يُحَلَّ الاسم إلى عنوان الوكيل، وألا يستبعد أي سجل CAA الجهة المستخدمة. ويجب أن يكون المنفذ 443 قابلاً للوصول من الإنترنت لتحدي
tls-alpn-01 وهو الافتراضي، وكذلك المنفذ 80 لتحدي http-01. وتوضح الوثائق أن Let's Encrypt يتحقق من عدة مواقع حول العالم، لذا قد يُفشل التصفية الجغرافية في المنبع عملية التحقق.استبعاد CDN لا يمرّر التحدي
تحذّر الوثائق من أن خدمة موضوعة أمام الوكيل، مثل Cloudflare، قد لا تمرّر بروتوكول ALPN
acme-tls/1. في هذه الحالة انتقل إلى NB_PROXY_ACME_CHALLENGE_TYPE=http-01. هذه الفحوص تستبعد أسباباً ولا تضمن النجاح: فقد تحقق مشارك من DNS ومن وضع Cloudflare على DNS فقط ومن فتح المنفذين 80 و443 ومن غياب CAA، ثم حصل على الخطأ نفسه مع نوعي التحدي.فحص Traefik الموضوع في المقدمة
إذا كان Traefik يمرّر TLS إلى الوكيل عبر موجّه TCP مع
tls.passthrough=true، فتأكد من أن نقطة دخول HTTPS تحمل allowACMEByPass=true. يشرح الإطار التالي ما يفعله هذا الخيار وما لا يثبته.
- مؤكَّد من الفريق — خطأ
permission denied على المجلد /certs ناتج عن صلاحيات نظام الملفات وليس عن إصدار الوكيل؛ أما التحذير failed to get active profile state المتعلق بملف تعريف العميل المدمج فلا علاقة له بالوكيل وليس حرجاً، ومن المقرر تصحيح رسالته في إصدار لاحق. - مُبلَّغ عنه من عدة مشاركين — إضافة
allowACMEByPass=true إلى نقطة دخول HTTPS في Traefik تفك الإصدار. يؤكد ذلك عدة مشاركين، لكن اثنين آخرين يقولان إن الخيار كان مضبوطاً لديهما أصلاً وإن التعطل مستمر، أحدهما مع الإصدار 0.74.4 من الوكيل. - مُبلَّغ عنه من مشارك واحد، غير متحقق منه — على NetBird Cloud، يفسّر بطءُ الإصدار لدى ZeroSSL مع مهلة مدتها 5 دقائق في مكتبة autocert الخاصة بلغة Go حالات الفشل. ويوضح كاتب التعليق أنه يستنتج من الخارج دون تأكيد من الفريق.
- غير مثبت — لا يوجد سبب واحد حتى اليوم: ما زال البلاغ يحمل الوسم
triage-needed عند الاطلاع عليه في 31 أكتوبر 2026. لا تقدّم أياً من هذه الاحتمالات على أنه سبب حالتك قبل أن تختبره.
يضبط السكربت getting-started.sh في مستودع NetBird الخيار --entrypoints.websecure.allowACMEByPass=true على Traefik. وبحسب وثائق Traefik، فإن هذا الخيار، المعطّل افتراضياً، يجعل موجّهاتك أنت تعالج تحديات ACME عبر TLS وHTTP بدل موجّه ACME الداخلي، ويسمح بمرور تحدي TLS-ALPN إلى موجّه TLS تعرّفه بنفسك. استخدم اسم نقطة الدخول الخاصة بك (websecure أو https…): فقد اضطر مشارك إلى ضبطه على نقطتي دخول HTTP وHTTPS معاً. وهو لا يغني عن قراءة السجل.
أصل مغلق: الحصول على الشهادة عبر DNS-01 مع lego
ما دامت الشهادة تعتمد على تحدي tls-alpn-01 أو http-01، فعلى الجهة المصدِّرة أن تصل إلى وكيلك من الإنترنت. وهذا يتعارض مع أصل مغلق إلا أمام نطاقات CDN، أو مع جدار حماية في المنبع لا تديره، أو مع تصفية جغرافية. يزيل تحدي dns-01 هذا الاعتماد: فهو يثبت التحكم بالنطاق عبر سجل TXT مؤقت يُنشأ بواسطة واجهة برمجة مزوّد DNS. حتى 31 أكتوبر 2026 لا يدمجه وكيل NetBird أصلاً: فالطلب، أي البلاغ netbird #5450 المفتوح في 25 فبراير 2026 والذي يضم 30 تعليقاً، ما زال مفتوحاً. لكن وثائق NetBird تصف طريقاً هو private proxy with lego: يحصل lego على شهادة wildcard ويجددها عبر DNS-01، ويقوم hook للنشر بنسخها إلى وحدة تخزين مشتركة، ثم يحمّلها الوكيل ويعيد تحميلها فوراً بعد كل تجديد. ويذكر أحد المشاركين في البلاغ أنه أعدّها دون صعوبة وأنها تصلح أيضاً لخدمات عامة.
- متغيرات الوكيل — يشير
NB_PROXY_WILDCARD_CERT_DIR إلى مجلد شهادة wildcard، ويفعّل NB_PROXY_PRIVATE="true" الوضع الخاص. ثبّت إصدار الصورة: يجب أن تدعم المتغيرين معاً. - الوضع الخاص لا يغلق شيئاً بمفرده —
NB_PROXY_PRIVATE لا يعطّل الاستماع العام. أزل بنفسك المنافذ العامة ومسارات الدخول إلى الوكيل. - نطاق wildcard — يغطي مستوى واحداً فقط من النطاقات الفرعية. أما اسم خارج التغطية فيعود إلى ACME المدمج، وهذا لا يمكن أن ينجح إذا كان الوكيل خاصاً بالكامل.
- انكشاف الشهادة — تسجّل الجهات العامة شهادة wildcard والنطاق الأساسي في سجلات Certificate Transparency، ومفتاح wildcard المخترق يمس كل الأسماء التي يغطيها.
- التشغيل — استخدم خادم ACME الإنتاجي لأن شهادات الاختبار غير موثوقة؛ وانسخ احتياطياً وحدتي تخزين lego والشهادات؛ وخطّط لجهة إصدار واحدة أو لتوزيع آمن لزوج الشهادة في حالة عنقود من عدة مضيفين.
سياسة التحكم في الوصول: أنشئ قاعدة تسمح فقط لمجموعة agency-ops بالوصول إلى المنفذ 22 على مجموعات العملاء. هذا يمنع أي جهاز مخترق في الـ mesh من أن يكون نقطة انطلاق للوصول إلى جميع خوادم العملاء.
الخلاصة: قواعد جدار حماية أقل، أمان حقيقي أكثر
NetBird 0.76 يمثل تحولاً جذرياً في إدارة أسطول خوادم VPS موزعة. بدلاً من ضرب قواعد UFW ومفاتيح WireGuard الثابتة، تحدد المجموعات والسياسات مرة واحدة — ويتولى مستوى التحكم الباقي. أمر netbird expose يذهب أبعد: يزيل الخدمات فعلياً من التعرض للإنترنت دون إعادة تهيئة جدار الحماية. للوكالة التي تدير عشرة عملاء أو شركة بمكاتب موزعة، هذا هو أكثر تقليص لسطح الهجوم أثراً بالساعة المستثمرة.
