كيف تشغّل خادم Tailscale الخاص بك باستخدام headscale

ما هو headscale

headscale هو تطبيق مستضاف ذاتياً لخادم التحكم في Tailscale، ولذلك يكون الجهاز الذي ينسّق شبكتك الخاصة عبارة عن VPS تملكه. هذا مشروع مجتمعي ولا تديره Tailscale Inc. وما زال كل جهاز يشغّل عميل tailscale الرسمي، مع توجيهه إلى خادمك باستخدام الخيار --login-server.

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

يخدم headscale شبكة tailnet واحدة (شبكة Tailscale واحدة) لكل مثيل، ويصفه المشروع بأنه مناسب للاستخدام الشخصي أو لمؤسسة صغيرة. مع ثلاثة أو أربعة أجهزة، يكون استخدام شبكة VPN عادية عبر WireGuard على VPS تملكه أقل من حيث البرامج التي تحتاج إلى تشغيلها، وأقل عرضة للأعطال. يصبح headscale مفيداً عندما لا تعود تريد كتابة كتلة [Peer] يدوياً لكل حاسوب محمول جديد. غالباً ما تكون التكلفة هي ما يدفع الأشخاص إلى البحث عن بدائل في البداية، لذلك من المفيد قراءة ما الذي تغطيه الخطة المجانية المستضافة فعلياً قبل تشغيل خادم، لأن عدداً قليلاً من أجهزتك الشخصية يندرج عادةً ضمنها. إذا كنت قد تجاوزت هذا الحد، فقارن التكلفة مع تكلفة الخطط المدفوعة، التي تُحسب لكل مستخدم لا لكل جهاز، لأن أفراد المنزل الذين يستخدمون حساباً واحداً قد يحافظون على تكلفة منخفضة حتى بعد أن يتوقف عدد الأجهزة عن كونه العامل المهم. إذا كنت تريد مستوى تحكم مستضافاً ذاتياً، لكنك تفضّل استخدام عميلك الخاص وواجهة ويب لإدارة الأقران بدلاً من بديل مطابق لـTailscale، فإن NetBird على VPS واحد هو البديل الذي يستحق التقييم. وللاطلاع على مقارنة أوسع بين النموذجين، راجع أوجه الاختلاف بين WireGuard وTailscale.

ما تحتاج إليه قبل التثبيت

• خادم VPS يعمل بنظام Ubuntu 24.04، وله عنوان IPv4 عام، ويتوفر لديك وصول عبر sudo. إذا كان الخادم جديداً، فاتبع أولاً الدقائق العشر الأولى على خادم VPS جديد.
• سجل DNS من النوع A يشير إلى ذلك العنوان. يستخدم هذا الدليل headscale.example.com.
• نطاق أو نطاق فرعي ثانٍ لاستخدام MagicDNS. يستخدم هذا الدليل tailnet.example.net. يجب ألا يكون النطاق نفسه المستخدَم في server_url.
• جهاز عميل واحد لضمّه، ويعمل بنظام Linux أو macOS أو Windows أو Android أو iOS.

تثبيت headscale من حزمة .deb الرسمية

ينشر المشروع حزم .deb في صفحة الإصدارات على GitHub. اعتباراً من يوليو 2026، الإصدار الحالي هو 0.29.3. تحقّق من البنية أولاً، لأن اسم الملف يتضمنها.

sudo apt update
sudo apt install -y wget
dpkg --print-architecture

يطبع ذلك amd64 على VPS عادي بمعمارية x86، وarm64 على خطة من نمط Ampere أو Graviton. ضع الإجابة في المتغير أدناه.

HEADSCALE_VERSION="0.29.3"
HEADSCALE_ARCH="amd64"
wget --output-document=headscale.deb \\
  "https://github.com/juanfont/headscale/releases/download/v${HEADSCALE_VERSION}/headscale_${HEADSCALE_VERSION}_linux_${HEADSCALE_ARCH}.deb"
sudo apt install -y ./headscale.deb
headscale version

البادئة ./ قبل اسم الملف مطلوبة. بدونها، يبحث apt عن حزمة باسم headscale.deb في مستودعاتك ويفشل.

تنشئ الحزمة مستخدم نظام headscale، وتكتب ملف إعداد افتراضياً هو /etc/headscale/config.yaml، وتثبّت وحدة systemd. لكنها لا تبدأ الخدمة، وهذا هو الترتيب الصحيح. يشير الإعداد الذي تأتي به الحزمة server_url إلى http://127.0.0.1:8080، وهو ليس عنواناً يمكن لأي عميل لديك الوصول إليه، لذلك ستكون الخدمة التي تبدأ الآن مضبوطة بشكل خاطئ حتى لو بدأت بنجاح. يؤدي تشغيل sudo systemctl is-active headscale في هذه المرحلة إلى طباعة inactive. هذا متوقع وليس عطلاً.

اضبط server_url قبل بدء الخدمة

حرّر /etc/headscale/config.yaml باستخدام sudo nano /etc/headscale/config.yaml، أو طبّق التغييرات الثلاثة نفسها باستخدام sed. احتفظ بنسخة من الملف الأصلي، لأن الملف طويل ويحتوي على تعليقات كثيرة، وهو أفضل مرجع متاح لك لبقية الإعدادات.

sudo cp /etc/headscale/config.yaml /etc/headscale/config.yaml.orig
sudo sed -i 's|^server_url:.*|server_url: https://headscale.example.com|' /etc/headscale/config.yaml
sudo sed -i 's|^listen_addr:.*|listen_addr: 127.0.0.1:8080|' /etc/headscale/config.yaml
sudo sed -i 's|^  base_domain:.*|  base_domain: tailnet.example.net|' /etc/headscale/config.yaml
sudo grep -E '^(server_url|listen_addr):|^  base_domain:' /etc/headscale/config.yaml

server_url هو العنوان الذي يكتبه headscale في كل تسجيل للعميل. سيتصل العملاء بهذه السلسلة النصية نفسها دائماً بعد ذلك، لذلك يجب أن تكون الاسم العام مسبوقاً بـ https://، وليس 127.0.0.1 أبداً.

listen_addr هو العنوان الذي ترتبط به العملية. اتركه على loopback. ينهي reverse proxy على الخادم نفسه TLS (أمان طبقة النقل) ثم يمرّر الاتصالات إليه، لذلك لا يحتاج أي طرف خارج الخادم إلى الوصول إلى المنفذ 8080.

base_domain هو لاحقة MagicDNS، أي النطاق الذي تحصل العقد على أسمائها تحته. يجب أن يكون اسم نطاق مؤهلاً بالكامل من دون نقطة في نهايته، وأن يكون مختلفاً عن النطاق الموجود في server_url، لأن مساحتي الأسماء ستتعارضان بخلاف ذلك.

اترك قسم قاعدة البيانات كما هو. الإعداد الافتراضي هو SQLite في /var/lib/headscale/db.sqlite، داخل دليل أنشأته الحزمة وتملك صلاحية إدارته، وSQLite كافٍ لشبكة tailnet بهذا الحجم.

Start headscale and prove it is running

sudo systemctl enable --now headscale
sudo systemctl is-active headscale
curl -sS -o /dev/null -w '%{http_code}\\n' http://127.0.0.1:8080/health

is-active prints active and the curl prints 200. enable --now does both halves of the job: it starts the service and it marks it to start after a reboot.

If is-active prints failed, read the journal with sudo journalctl -u headscale -n 50 --no-pager. A failure at this stage is nearly always the configuration file, because headscale parses the whole file before it opens a socket, so a bad indent or an unknown key stops the process before anything listens. Fix the file, then sudo systemctl restart headscale. Every later configuration change needs that same restart. Clients reconnect on their own afterwards. If systemd units are new to you, running your own services and timers with systemd covers the commands used here.

Check the state files while you are in the shell:

stat -c '%U %n' /var/lib/headscale/db.sqlite /var/lib/headscale/noise_private.key

Both lines start with headscale, the unprivileged user the package created. noise_private.key is the server's identity to its clients. Keep it. If you delete it, headscale generates a new one and every node has to register again.

ضع TLS أمام headscale

يجب أن تصل العملاء إلى server_url عبر HTTPS. يُعد Caddy أقصر طريق، لأنه يطلب الشهادة ويجددها تلقائياً.

sudo apt install -y caddy

استبدل /etc/caddy/Caddyfile بالكتلة الواردة في وثائق headscale:

headscale.example.com {
    reverse_proxy 127.0.0.1:8080 {
        header_up True-Client-IP {remote_host}
        header_up X-Real-IP {remote_host}
    }
}

sudo caddy validate --adapter caddyfile --config /etc/caddy/Caddyfile
sudo systemctl restart caddy
sudo systemctl is-active caddy

يعرض validate القيمة adapted config to JSON عند تحليل الملف بنجاح. أما التحذير من أن الملف غير منسّق فهو تجميلي. ومن جهازك المحمول، يجب أن يعرض curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health القيمة 200 أيضاً. يثبت هذا الاختبار الواحد أن DNS والجدار الناري والشهادة والوكيل تعمل معاً.

إليك تفصيلاً في الوكيل يسبب مشكلات قد تستغرق حلّها ساعات. اتصال التحكم في Tailscale هو ترقية HTTP، ويبدأ باستخدام POST بدلاً من GET، وقيمة ترويسة Upgrade هي tailscale-control-protocol. يمرر Caddy ذلك من دون إعداد إضافي. أما nginx فلا يفعل ذلك، لذلك تحتاج واجهة nginx الأمامية إلى خريطة الترقية:

map $http_upgrade $connection_upgrade {
    default keep-alive;
    ''      close;
}

server {
    listen 443 ssl;
    server_name headscale.example.com;
    location / {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_buffering off;
        proxy_pass http://127.0.0.1:8080;
    }
}

إذا حذفت هذه الأسطر، فستظل الطلبات العادية ناجحة. لذلك يعرض /health الرمز 200 ويبدو كل شيء سليماً، بينما لا يتكوّن اتصال التحكم طويل الأمد، وتسجّل العقد نفسها ثم تبقى غير متصلة. إذا اخترت استخدام nginx، فإن إعداد Certbot على Ubuntu 24.04 مع nginx يشرح جانب الشهادة.

المنافذ التي يجب فتحها في UFW

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

ينقل المنفذ 443 كل اتصالات العملاء. ويُستخدم المنفذ 80 فقط لتحدي HTTP الخاص بـACME (بيئة الإدارة التلقائية للشهادات) ولإعادة التوجيه إلى HTTPS، كما يحتاج Caddy إلى هذا المنفذ للحصول على شهادة.

يبقى المنفذ 8080 مغلقاً. listen_addr هو 127.0.0.1:8080، لذلك يصل الـproxy إلى headscale عبر واجهة loopback ولا تكون هناك حاجة إلى قاعدة جدار ناري. يؤدي فتح المنفذ 8080 أمام الإنترنت إلى توفير قناة تحكم غير مشفّرة للعملاء من دون أي فائدة. تذكّر أن معظم موفري الخدمة يشغّلون جداراً نارياً ثانياً في لوحة التحكم لديهم، منفصلاً عن UFW، لذلك قد يكون المنفذ مفتوحاً على الخادم لكنه مغلقاً عند الحافة. يشرح أساسيات جدار UFW على VPS بنية القواعد بمزيد من التفصيل.

إنشاء مستخدم ومفتاح preauth

sudo headscale users create alice
sudo headscale users list

الأمر headscale هو عميل. يتصل بالـdaemon قيد التشغيل عبر Unix socket الموجود في /var/run/headscale/headscale.sock، والذي وضعه 0770 وتملكه مجموعة headscale. وينتج عن ذلك أمران. يفشل الأمر عندما تكون الخدمة متوقفة، وهذا سبب آخر لأهمية ترتيب الخطوات في هذا الدليل. كما يتطلب الأمر sudo، ما لم تضف حسابك إلى مجموعة headscale.

يطبع users list معرّفاً بجانب كل اسم. تحتاج إلى هذا الرقم، لأن أمر المفتاح يتطلب معرّف مستخدم رقمياً وليس اسماً.

sudo headscale preauthkeys create --user 1 --expiration 24h

يُطبع المفتاح مرة واحدة فقط. انسخه الآن. مفتاح preauth صالح للاستخدام مرة واحدة ولمدة ساعة واحدة، ما لم تحدد خلاف ذلك؛ لذلك يجدر بك ضبط --expiration 24h أثناء الاختبار. أضف --reusable لمفتاح يضم عدة أجهزة، وتعامل معه كما تتعامل مع كلمة مرور، لأن أي شخص يملكه يمكنه الانضمام إلى شبكتك.

اربط أول عميل باستخدام --login-server

على الجهاز الذي تريد ضمّه:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --login-server https://headscale.example.com --auth-key 'hskey-auth-PASTE-YOUR-KEY-HERE'
tailscale status
tailscale ip -4

يطبع tailscale ip -4 العنوان الذي عيّنه headscale، ويكون شبيهاً بـ100.64.0.1. على الخادم، يعرض sudo headscale nodes list العقدة مع معرّفها ومستخدمها وحالتها، أي ما إذا كانت متصلة.

يجب أن تتطابق قيمة --login-server مع server_url تماماً، بما في ذلك scheme ومن دون شرطة مائلة في النهاية. تجري مقارنتهما كسلسلتين نصيتين. ويؤدي عدم التطابق إلى تسجيل العميل عنواناً، ثم إخباره بالتواصل مع عنوان آخر.

يحتفظ الجهاز الذي سُجّل سابقاً في خدمة Tailscale المستضافة بعملية تسجيل الدخول تلك. شغّل sudo tailscale logout عليه أولاً، ثم شغّل tailscale up مع --login-server.

إذا حذفت --auth-key، يطبع العميل عنوان URL بدلاً من ذلك. افتحه، وستعرض الصفحة المعرّف الخاص بمحاولة التسجيل هذه. وافق على المحاولة من الخادم:

sudo headscale auth register --user alice --auth-id PASTE-THE-ID-FROM-THE-PAGE

هذا النموذج أسهل عند استخدام حاسوبك المحمول. أما مفاتيح التسجيل المسبقة فهي أفضل لأي شيء يُنفَّذ بواسطة script، لأنك لا تحتاج إلى وجود شخص للمراقبته. بعد أن يصبح VPS نفسه عقدة، يمكنه أيضاً تمرير حركة الإنترنت الخاصة بأجهزتك الأخرى. وهذا هو إعداد عقدة الخروج، مع اختلاف واحد: توافق على المسار المُعلن على الخادم باستخدام الأمر headscale، بدلاً من ذلك داخل وحدة تحكم إدارية مستضافة. إذا كنت تريد الوصول إلى شبكة خاصة موجودة خلف VPS، وليس وسيلة للخروج إلى الإنترنت، فتغطي خطوة الموافقة نفسها إعلان تلك الشبكة الفرعية لبقية tailnet. أما نشر تطبيق واحد من عقدة، بدلاً من توجيه شبكات كاملة عبرها، فهو مهمة مختلفة، ويمثل serve وfunnel الطريقتين لتنفيذ ذلك، مع اعتماد كليهما على آلية الشهادات وingress الخاصة بـTailscale. لذلك تعامل معهما كميزتين لـtailnet المستضاف، لا كشيء يوفّره headscale لك.

DERP، وما الذي يمرّر حركة الشبكة عند فشل المسار المباشر

DERP ‏(مرحل مشفّر مخصّص للحزم) هو مسار الرجوع الاحتياطي. عندما يتعذر على عقدتين فتح اتصال WireGuard مباشر، ويحدث ذلك عادةً لأن كلتيهما خلف NAT صارم (ترجمة عناوين الشبكة)، فإنهما ترسلان الحزم عبر مرحل بدلاً من ذلك. لا يحتفظ المرحل بأي مفاتيح، لذلك لا يستطيع قراءة حركة الشبكة لديك. لكنه يرى العقد التي تتواصل ومقدار البيانات المنقولة.

انتبه إلى ما يفعله الإعداد الافتراضي. يأتي Headscale مُعدّاً للإشارة إلى https://controlplane.tailscale.com/derpmap/default مع auto_update_enabled: true وupdate_frequency: 3h، ولذلك تكون طبقة التحكم مملوكة لك، بينما تكون مرحلاتك تابعة لـTailscale. هذا حل مناسب لمعظم المستخدمين. إذا لم يناسبك ذلك، فشغّل مرحلك الخاص.

لتشغيل مرحلك الخاص، عيّن enabled: true ضمن derp.server في config.yaml، ثم أعد تشغيل headscale، وافتح منفذ STUN (أدوات اجتياز الجلسات لـNAT) باستخدام sudo ufw allow 3478/udp. يوضح ملف الإعداد المتطلب صراحةً: يجب أن يستخدم server_url البروتوكول https، لأن DERP يتطلب TLS. يؤدي إفراغ قائمة derp.urls إلى إزالة مرحلات Tailscale من الخريطة. وإذا فعلت ذلك من دون مرحل مضمّن يعمل، فلن تتمكن أي عقدتين لا تستطيعان الاتصال مباشرةً من الاتصال إطلاقاً.

من جهاز عميل، يطبع tailscale netcheck زمن الاستجابة لكل منطقة ترحيل يعرفها، ويضع tailscale status علامة على كل نظير بوصفه إما direct مع عنوان أو relay مع رمز المنطقة. إذا ظل النظير في حالة relay، فالمشكلة في NAT وليست في headscale. أما النظير الذي يكون direct ومع ذلك يبقى بطيئاً، فهذه مسألة مختلفة، والإجابة المعتادة هنا هي MTU وليست النفق نفسه.

لماذا تظهر العقدة على أنّها غير متصلة؟

الوكيل الوسيط يسقط طلب الترقية. هذه هي الحالة الأكثر شيوعاً. علامتها أنّ كل شيء آخر يبدو سليماً: يعرض /health الحالة 200، ويعرض headscale nodes list العقدة، لكنّ العقدة لا تصبح متصلة أبداً. اتصال التحكم هو طلب POST يحمل Upgrade: tailscale-control-protocol، وأي وكيل وسيط لا يمرّره يقطع القناة الوحيدة التي تُبلغ عن حالة العقدة. قارن إعداد Nginx لديك مع كتلة map أعلاه، أو انتقل إلى Caddy لاستبعاد الوكيل الوسيط.

تغيّرت قيمة server_url بعد تسجيل العقد. تستمر العقد في الاتصال بالقيمة التي أُعطيت لها عند التسجيل. إذا عدّلتها، فنفّذ sudo tailscale up --login-server https://headscale.example.com --force-reauth على كل عقدة.

العميل لا يعمل. على العقدة، نفّذ sudo systemctl is-active tailscaled وsudo journalctl -u tailscaled -n 50 --no-pager. يسجّل العميل الذي لا يستطيع حل نطاقك أو الوصول إليه محاولات إعادة الاتصال في ذلك الموضع.

انتهت صلاحية المفتاح. يشرح القسم التالي هذه الحالة.

لمراقبة جهة الخادم أثناء الاختبار، نفّذ sudo journalctl -u headscale -f على VPS، وأعد تشغيل tailscaled على العميل. تُنتج العقدة التي تصل إلى headscale أسطر سجل فوراً. يعني غياب هذه الأسطر أنّ الطلب لا يصل، لذا افحص DNS والجدار الناري والوكيل الوسيط قبل فحص headscale.

انتهاء صلاحية المفاتيح، والعقدة التي تتوقف عن العمل بعد أسابيع

هناك نوعان منفصلان من انتهاء الصلاحية، والخلط بينهما يضيّع الوقت.

تنتهي صلاحية مفاتيح Preauth بسرعة عمداً. الإعداد الافتراضي هو ساعة واحدة واستخدام واحد. إذا رفضت tailscale up المفتاح، فأنشئ مفتاحاً جديداً على الخادم بدلاً من تعديل أي شيء على العميل.

مفاتيح العقد هي الجزء طويل الأجل. يحدد قسم node في config.yaml قيمة expiry: 0، وتعني 0 عدم وجود انتهاء صلاحية افتراضي: تظل العقدة المسجّلة صالحة حتى تنهي صلاحيتها. أما العقد الموسومة فلا تنتهي صلاحيتها مطلقاً. عيّن expiry: 180d إذا أردت أن تنتهي صلاحية التسجيلات تلقائياً، وافهم ما يترتب على ذلك: ستحتاج كل عقدة غير موسومة إلى sudo tailscale up --login-server https://headscale.example.com --force-reauth وفق ذلك الجدول، وسينقطع خادم لا يعتمد على واجهة رسومية ولا يعيد أحد مصادقته عن الشبكة تلقائياً.

نفّذ ذلك يدوياً عندما يفقد أحدهم حاسوباً محمولاً. يعرض sudo headscale nodes list المعرّف، ثم يسجّل sudo headscale nodes expire -i 3 خروج تلك العقدة، ويزيلها sudo headscale nodes delete -i 3 من الشبكة بالكامل.

النسخ الاحتياطية والترقيات

يشكّل /var/lib/headscale و/etc/headscale معاً الخادم بأكمله. أوقف الخدمة قبل نسخهما، لأن SQLite قد ينفّذ عمليات كتابة جارية، وقد تكون قاعدة البيانات غير متسقة إذا نُسخت أثناء التشغيل تحت الحمل.

sudo systemctl stop headscale
sudo tar czf /root/headscale-state.tgz -C /var/lib headscale
sudo tar czf /root/headscale-config.tgz -C /etc headscale
sudo systemctl start headscale
sudo chmod 600 /root/headscale-*.tgz

انقل الملفين خارج الخادم. فهما يحتويان على المفاتيح الخاصة وجميع التسجيلات، ولذلك يجب التعامل معهما بالعناية نفسها التي تتطلبها حماية الخادم. يشرح النسخ الاحتياطية باستخدام restic من VPS كيفية تنفيذ ذلك وفق جدول زمني وبطريقة مشفّرة.

تتبع الترقيات خطوات التثبيت نفسها: نزّل .deb وsudo apt install ./headscale.deb الجديدين، ثم أعد تشغيل الخدمة وأعد تنفيذ اختبارات is-active و/health. منذ الإصدار 0.29، أصبح مسار الترقية صارماً. لا يُسمح بتجاوز إصدار فرعي، كما لا يُسمح بالرجوع إلى إصدار فرعي أقدم. انتقل إصداراً فرعياً واحداً في كل مرة، وخذ نسخة احتياطية قبل كل خطوة، واقرأ ملاحظات إصدار ذلك الإصدار أولاً، لأن الإصدار نفسه غيّر سلوك سياسة ACL ونقل عدة مفاتيح إعدادات.

FAQ

لماذا يفشل headscale في البدء مباشرة بعد تثبيت ملف .deb؟

تثبّت الحزمة الوحدة، لكنها تترك الخدمة متوقفة، كما أن /etc/headscale/config.yaml الافتراضي قالب وليس إعداداً صالحاً للتشغيل. عدّل server_url وlisten_addr وbase_domain أولاً، ثم شغّل sudo systemctl enable --now headscale وتحقق باستخدام sudo systemctl is-active headscale. إذا استمر الفشل، يحدد sudo journalctl -u headscale -n 50 --no-pager المشكلة. وفي هذه المرحلة يكون السبب غالباً خطأً في YAML، لأن headscale يحلل الملف بأكمله قبل أن يستمع على منفذ.

هل ما زلت أحتاج إلى تثبيت عميل Tailscale العادي على أجهزتي؟

نعم. يستبدل headscale خادم التحكم فقط. يشغّل كل عقدة العميل الرسمي من Tailscale، وتوجّهه إلى خادمك باستخدام sudo tailscale up --login-server https://headscale.example.com. هذا الخيار موجود في العميل القياسي، لذلك لا حاجة إلى تصحيحه أو إعادة بنائه.

هل تمر حركة الشبكة عبر خادم headscale؟

عادةً لا. ينسّق headscale الشبكة ويوزّع المفاتيح والعناوين، بينما يمر مسار البيانات مباشرةً عبر WireGuard بين عقدك. لا تسلك حركة الشبكة مساراً بديلاً إلا عندما يتعذر على عقدتين الوصول إلى بعضهما مباشرةً وتنتقلان إلى مرحّل DERP. ومع الإعداد الذي توفره الحزمة، تكون هذه المرحلات العامة التابعة لـTailscale. شغّل tailscale status على عقدة لمعرفة ما إذا كان نظير معيّن direct أو يستخدم relay.

لماذا تبقى عقدتي غير متصلة بعد تسجيلها؟

العقدة التي تظهر في headscale nodes list لكنها لا تصبح متصلة أبداً تكون قد فقدت عادةً اتصال التحكم عبر Reverse Proxy. هذا الاتصال هو ترقية HTTP تُرسل باستخدام POST مع الرأس Upgrade: tailscale-control-protocol، ويسقطه nginx ما لم تضف كتلة map $http_upgrade $connection_upgrade والأسطر المطابقة proxy_set_header. يمرّر Caddy هذا الاتصال دون إعداد إضافي، ولذلك يمثل طريقة سريعة لاختبار ما إذا كان Reverse Proxy هو سبب المشكلة.

هل أحتاج إلى اسم نطاق وTLS من أجل headscale؟

نعم، عملياً. يتصل العملاء بالسلسلة التي تضعها في server_url، وتُصدر الشهادات للأسماء لا لعناوين IP مجردة، كما ينص ملف الإعداد على أن DERP يتطلب TLS. يستغرق ربط نطاق مع Caddy نحو خمس دقائق، ويوفر نقطة نهاية HTTPS تجدّد شهادتها تلقائياً. يعني تشغيل خادم التحكم عبر HTTP العادي أن كل اتصال بين العملاء والخادم يمر عبر الإنترنت دون تشفير.