إعدادات Tailscale

يتضمن Chute شبكات Tailscale الأصلية المدمجة. بعد الإعداد، يمكنك الإشارة إلى السياسة المدمجة TAILSCALE من القواعد أو مجموعات السياسات لتوجيه حركة المرور عبر tailnet الخاص بك — الوصول إلى الأجهزة الأخرى في الـ tailnet، أو الخروج عبر عقدة خروج (exit node)، أو الوصول إلى الشبكات الفرعية التي يعلن عنها الأقران.

على عكس بروتوكولات الوكيل العادية، لا يتم تعريف Tailscale كسياسة سطر بسطر في [Proxy]؛ بل يتم إعداده عبر قسم [Tailscale] واحد فريد عالميًا. يقوم بتسجيل العقدة في خادم التحكم باستخدام مفتاح مصادقة (auth key)، دون الحاجة إلى تسجيل دخول تفاعلي عبر المتصفح.

قسم Tailscale

يحدد قسم [Tailscale] كل ما يحتاجه الجهاز للانضمام إلى tailnet:

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
control-server = https://controlplane.tailscale.com
hostname = my-device
exit-node = 100.101.102.103
accept-routes = true
force-derp = false

ملاحظة: يُسمح بقسم [Tailscale] واحد فقط في ملف الإعداد بأكمله. يُعتبر قسم [Tailscale] المكرر خطأً في الإعداد. ويرجع ذلك إلى أن محرك Tailscale ثقيل ونطاقات عناوين tailnet متنافية مع بعضها — يمكن الانضمام إلى tailnet واحد فقط في كل مرة.

المعاملات

تقبل القيم المنطقية الصيغ التالية (بدون حساسية لحالة الأحرف): true/false، 1/0، yes/no، on/off.

ملاحظة: يتم تجاهل المفاتيح غير المعروفة مع تحذير (ولا تمنع تحميل الإعداد). الخطأ الإملائي في مفتاح (مثل كتابة force-derp كـ force_derp) سيعطل هذا الخيار بصمت — يرجى التحقق مقابل الجدول أعلاه.

السياسة المدمجة TAILSCALE

بمجرد إعداد قسم [Tailscale]، يصبح معرف السياسة المدمجة TAILSCALE متاحًا — فهو يقف جنبًا إلى جنب مع DIRECT و REJECT ويمكن الإشارة إليه مباشرة في القواعد ومجموعات السياسات. عندما لا يكون قسم [Tailscale] مُعدًا، أو عندما يكون Tailscale مُطفأً، تعود القواعد التي تشير إلى TAILSCALE إلى REJECT (فشل مغلق).

[Proxy Group]
Mesh = select, TAILSCALE, DIRECT

[Rule]
IP-CIDR,100.64.0.0/10,TAILSCALE,no-resolve
FINAL,DIRECT

التوجيه التلقائي

عند تمكين Tailscale، يقوم Chute تلقائيًا بإدراج القواعد الثلاثة التالية قبل جميع قواعدك، لذلك عادةً لا تحتاج إلى كتابة قواعد يدوية للوصول إلى tailnet:

DOMAIN-SUFFIX,ts.net,TAILSCALE
IP-CIDR,100.64.0.0/10,TAILSCALE,no-resolve
IP-CIDR6,fd7a:115c:a1e0::/48,TAILSCALE,no-resolve

هذه القواعد المُدرجة خاصة بوقت التشغيل فقط ولا تعدل ملف الإعداد أبدًا. عند ضبط accept-routes = true، يتم أيضًا إدراج الشبكات الفرعية التي يعلن عنها الأقران تلقائيًا كقواعد IP-CIDR / IP-CIDR6 مقابلة، وتُحدَّث تلقائيًا عند إضافة الأقران للشبكات الفرعية أو سحبها.

الاستخدام

الوصول إلى الأجهزة في tailnet

بمجرد إعداد قسم [Tailscale]، لا يحتاج الوصول إلى الأجهزة الأخرى في tailnet إلى قواعد إضافية — فالقواعد المُدرجة تغطي بالفعل نطاقات tailnet ولاحقة MagicDNS. يمكنك معالجة الأقران مباشرة باسم MagicDNS أو عنوان IP لـ tailnet:

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
hostname = my-iphone

[Rule]
FINAL,DIRECT

الآن ستمر الأهداف مثل my-pc.<tailnet>.ts.net أو 100.101.102.103 عبر Tailscale تلقائيًا.

الخروج عبر عقدة خروج

اضبط TAILSCALE كهدف FINAL لتوجيه كل حركة المرور التي لا تطابق قاعدة أكثر تحديدًا عبر عقدة الخروج:

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
exit-node = 100.101.102.103

[Rule]
FINAL,TAILSCALE

ملاحظة: تعيين exit-node وحده لا يوجّه أي حركة مرور عبر عقدة الخروج — يجب أيضًا إضافة قاعدة تُرسل حركة المرور إلى TAILSCALE (على سبيل المثال FINAL,TAILSCALE). بدون هذه القاعدة تكون عقدة الخروج مُهيّأة لكنها غير مُستخدَمة؛ ويُنبّه محرّر الإعدادات في التطبيق إلى ذلك.

قبول مسارات الشبكات الفرعية

عندما يعمل جهاز في tailnet كموجّه شبكة فرعية (subnet router) ويعلن عن شبكات فرعية محلية، فعّل accept-routes = true للوصول إلى تلك الشبكات الفرعية؛ يتم إدراج قواعد التوجيه المقابلة تلقائيًا:

[Tailscale]
auth-key = tskey-auth-xxxxxxxxxxxx
accept-routes = true

خادم تحكم مخصص (Headscale)

بالإضافة إلى مستوى التحكم الرسمي، يدعم Chute أيضًا خوادم تحكم Headscale / Ionscale ذاتية الاستضافة. ما عليك سوى ملء عنوان URL المقابل:

[Tailscale]
auth-key = your-headscale-preauth-key
control-server = https://headscale.example.com
hostname = my-device

لا تفرض خوادم التحكم الخاصة بطرف ثالث البادئة tskey- وتقبل مفاتيح المصادقة الخاصة بها. يُنصح باستخدام عنوان http:// نصّي فقط على شبكة موثوقة (مثل Headscale مستضاف ذاتيًا محليًا).

القيود المعروفة وأفضل الممارسات

تركز تطبيقات Tailscale على القدرات الأكثر استخدامًا في سيناريوهات الوكيل؛ لا تُدعم بعض ميزات العميل الرسمي بعد. يرجى ملاحظة الاختلافات السلوكية التالية:

1. استخدم force-derp = true كخيار لاستكشاف الأخطاء وإصلاحها فقط. يفضّل Chute عادةً اتصالات UDP المباشرة مع الأقران (disco hole-punching)، وهي غالبًا أقل زمنًا وأكثر إنتاجية من ترحيل DERP. إذا كانت الاتصالات المباشرة غير مستقرة باستمرار أو أبطأ من DERP على شبكة محددة، فقارن بين الوضعين وفعّل force-derp لتلك البيئة فقط.

2. يُدعم تسجيل الدخول بمفتاح المصادقة فقط. لا يتم دعم SSO / تسجيل الدخول التفاعلي عبر المتصفح، وTailscale SSH، وTaildrop، وFunnel / serve. كذلك لا يستطيع Chute الإعلان عن مسارات الشبكات الفرعية المحلية أو تقديم هذا الجهاز كعقدة خروج؛ فهو ينضم كمستهلك فقط.

3. يبقى حل DNS العادي محليًا عند استخدام عقدة خروج. لا يرسل Chute طلبات حل DNS العادية عبر عقدة الخروج المحددة. تُحل أسماء MagicDNS محليًا من خريطة tailnet. لا تُدعم المحللات العامة أو محللات split-DNS البعيدة؛ استخدم عنوان IP عندما لا يمكن حل اسم خاص إلا على الشبكة البعيدة.

4. يدعم MagicDNS سجلات A / AAAA فقط. يتم تجاهل أدوات الحل (Resolvers) العامة، ومسارات DNS-المقسم (إدخالات ذات أدوات حل مخصصة)، و ExtraRecords غير العنوانية (TXT / CNAME / SRV)؛ يتم تسجيل تحذير عند الكشف عنها.

5. تم إصلاح MTU الداخلي للمسار المباشر عند 1280. لا يوجد اكتشاف لـ Path MTU؛ هذه القيمة المحافظة تمنع الثقوب السوداء على روابط PPPoE / الأنفاق المتراكمة. مسار تتابع DERP غير متأثر.

6. لا يُدعم قفل Tailnet (قفل الشبكة). في tailnet مع تمكين قفل الشبكة، لن يتم توقيع مفتاح هذه العقدة، وسيقوم الأقران المقفلون بإسقاط حركة المرور من هذا الجهاز بصمت.

7. سيناريوهات Mullvad exit وإعادة كتابة المصدر غير متاحة. ميزات عقدة الخروج التي تتطلب إعادة كتابة عنوان المصدر المحلي لم تُنفذ بعد.

8. يعتمد الاسترداد بعد تغيير الشبكة على إشعار النظام. عند التبديل بين Wi-Fi / الخلوي، يعيد Chute بناء الاتصالات على الفور؛ في الحالة النادرة التي لا يُستقبل فيها إشعار تغيير الشبكة، يعود الاسترداد إلى إعادة اتصال مراقب (watchdog) لمدة تقريبًا 3 دقائق.