ACL Headscale لفريق موزع: تأمين mesh داكار/أبيدجان/الدار البيضاء

📍 المقالة الرئيسية: Headscale 2026: الدليل الكامل.

دون ACL، Headscale الخاص بك شبكة مسطحة حيث كل جهاز يمكنه الوصول إلى كل آخر على جميع المنافذ. لفريق من 30 شخصاً موزع بين داكار وأبيدجان والدار البيضاء، هذا anti-pattern أمني كبير. هذا الدرس يفصل تنفيذ سياسات HuJSON قوية: مستخدمون، مجموعات، tags، تراخيص دقيقة، أمثلة جاهزة للنسخ.

المتطلبات

Headscale في الإنتاج، 5 أجهزة مسجلة على الأقل، فهم RBAC. المستوى: متوسط/متقدم. الوقت: 2 إلى 3 ساعات.

الخطوة 1 — فهم بنية HuJSON

سياسة Headscale تحتوي على خمسة أقسام رئيسية: groups (مجموعات المستخدمين، مكافئة لمجموعات RBAC)، tagOwners (من يمكنه تعيين أي tags)، autoApprovers (طرق و exit nodes معتمدة مسبقاً)، acls (قواعد التراخيص الفعلية)، ssh (قواعد SSH خاصة عبر Tailscale SSH).

الخطوة 2 — تعريف المستخدمين والمجموعات

في /etc/headscale/policy.hujson، نُعرِّف المجموعات حسب الأدوار في الشركة. كل مستخدم ينتمي إلى مجموعة أو أكثر. المسؤولون يحصلون على وصول كامل، المطورون على staging و prod، التسويق على Vaultwarden فقط.

{
  "groups": {
    "group:admins": ["amadou@votre-entreprise.com"],
    "group:devs": ["amadou@...", "fatou@...", "ousmane@..."],
    "group:marketing": ["aicha@...", "moussa@..."],
    "group:finance": ["khadija@..."],
    "group:freelances": ["consultant1@external.com"]
  },
  "tagOwners": {
    "tag:server-prod": ["group:admins"],
    "tag:server-staging": ["group:devs"],
    "tag:database-prod": ["group:admins"],
    "tag:office-dakar": ["group:admins"]
  }
}

الخطوة 3 — تعريف ACL الرئيسية

القواعد التالية تطبق مبدأ الامتياز الأدنى. المسؤولون لديهم وصول إلى كل شيء، المطورون مقيدون بـ staging و SSH على prod، التسويق محدود بثلاثة تطبيقات، المستقلون يصلون فقط إلى staging.

"acls": [
  // المسؤولون لديهم وصول كامل
  {
    "action": "accept",
    "src": ["group:admins"],
    "dst": ["*:*"]
  },
  // المطورون: SSH على staging و prod، وصول للتطبيقات الداخلية
  {
    "action": "accept",
    "src": ["group:devs"],
    "dst": ["tag:server-staging:22,80,443,5432,6379"]
  },
  {
    "action": "accept",
    "src": ["group:devs"],
    "dst": ["tag:server-prod:443"]
  },
  // التسويق: وصول إلى Vaultwarden، Outline، Plausible فقط
  {
    "action": "accept",
    "src": ["group:marketing"],
    "dst": ["100.64.0.10:443", "100.64.0.11:443", "100.64.0.12:443"]
  },
  // المستقلون: staging فقط
  {
    "action": "accept",
    "src": ["group:freelances"],
    "dst": ["tag:server-staging:80,443"]
  }
]

الخطوة 4 — SSH مع Tailscale SSH

Tailscale SSH (و Headscale SSH) يسمح بـ SSH دون مفتاح عام، حيث المصادقة يديرها mesh. هذا يبسط إدارة المفاتيح ويحسن الأمن.

"ssh": [
  // المسؤولون يمكنهم SSH في كل مكان كـ root
  {
    "action": "accept",
    "src": ["group:admins"],
    "dst": ["tag:server-prod", "tag:server-staging"],
    "users": ["root", "ubuntu", "debian"]
  },
  // المطورون يمكنهم SSH على staging بـ user الخاص بهم
  {
    "action": "accept",
    "src": ["group:devs"],
    "dst": ["tag:server-staging"],
    "users": ["autogroup:nonroot"]
  },
  // المطورون يمكنهم SSH على prod مع check 2FA
  {
    "action": "check",
    "src": ["group:devs"],
    "dst": ["tag:server-prod"],
    "users": ["autogroup:nonroot"],
    "checkPeriod": "1h"
  }
]

الخطوة 5 — اختبار السياسة قبل التطبيق

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

headscale policy check -f /etc/headscale/policy.hujson
# يعيد: Policy is valid

headscale policy set -f /etc/headscale/policy.hujson
# يعيد: Policy applied successfully

الخطوة 6 — تعيين tags للخوادم

على خادم Postgres الإنتاج، نُعلن عن tags المناسبة. ثم في Headscale، نعتمد التعيين.

tailscale up --login-server=https://headscale.votre-entreprise.com \
  --auth-key=PREAUTH \
  --advertise-tags=tag:server-prod,tag:database-prod

headscale nodes tag -i ID_DU_NODE -t tag:server-prod,tag:database-prod

الخطوة 7 — التدقيق والامتثال

كل عمليات Headscale مسجلة. للتدقيق الشهري، استخرج العمليات المتعلقة بالسياسات والتسجيلات. لشركة خاضعة لـ RGPD أو ARTCI، صدِّر هذه السجلات إلى Loki + Grafana مع احتفاظ سنة على الأقل.

journalctl -u headscale --since "1 month ago" | grep -i "policy\|tag\|register"

حالة خاصة: فريق متعدد المواقع

لفريق موزع على 3 مدن (داكار، أبيدجان، الدار البيضاء)، تعريف tags جغرافية يسمح بكتابة قواعد من نوع «مطورو داكار يمكنهم SSH خوادم داكار، نفس الشيء أبيدجان».

"groups": {
  "group:devs-dakar": [...],
  "group:devs-abidjan": [...],
  "group:devs-casa": [...]
},
"tagOwners": {
  "tag:server-dakar": ["group:devs-dakar"],
  "tag:server-abidjan": ["group:devs-abidjan"],
  "tag:server-casa": ["group:devs-casa"]
},
"acls": [
  {"action": "accept", "src": ["group:devs-dakar"], "dst": ["tag:server-dakar:*"]},
  {"action": "accept", "src": ["group:devs-abidjan"], "dst": ["tag:server-abidjan:*"]},
  {"action": "accept", "src": ["group:admins"], "dst": ["*:*"]}
]

الأخطاء الشائعة

التكيف مع السياق المغاربي وغرب إفريقيا

ثلاث تعديلات ملموسة. المستقلون والمتدربون: متكررون جداً في إفريقيا، أنشئ مجموعة مخصصة group:temporaires مع ACL صارمة (staging only، منافذ محدودة، SSH للقراءة فقط). المواقع الموزعة: لمكتب محاماة في الدار البيضاء/طنجة/مراكش، tagging كل موقع يسمح بعزل الموارد المحلية. التوافق مع ARTCI: اطلب ACL في القراءة/الكتابة على خوادم الإنتاج فقط للحسابات القابلة للتتبع.

دروس الإخوة

• نشر Headscale
• Headscale + Coolify: PaaS ذاتي الاستضافة

الأسئلة المتكررة

كم قاعدة ACL يدعم Headscale؟ عدة مئات دون تأثير ملحوظ.

كيفية تدقيق من وصل إلى ماذا؟ سجلات Headscale + سجلات SSH من جانب الخوادم. تقاطع الاثنين يعطي أثراً كاملاً.

سياسة HuJSON Tailscale Cloud متوافقة؟ 95% نعم.

للاستزادة

• 🔝 المرجع: الدليل الكامل Headscale 2026