ماذا يجب أن تتحقق منه عندما لا يتمكن Tailscale من الوصول إلى خادم منزلك؟

عندما لا يستطيع Tailscale الوصول إلى خادمك المنزلي، لا يكون الفشل دائمًا داخل شبكة Tailscale نفسها. قد يكون الخادم غير متصل، أو قد لا يحل اسم الجهاز، أو قد ترفض قاعدة الوصول الاتصال، أو قد يحجب جدار حماية نظام التشغيل الخدمة، أو قد يكون التطبيق يستمع فقط على localhost.

أسرع طريقة للعثور على السبب هي استكشاف الأخطاء حسب الطبقات. أولاً تأكد من أن كلا العقدتين في Tailscale متصلتان. ثم اختبر عنوان IP الخام للخادم في Tailscale، وافصل بين اتصال العقدة الأساسي والوصول إلى التطبيق، ولا تنتقل إلى توجيه الشبكة الفرعية أو استكشاف أخطاء DERP إلا عندما تشير الأعراض فعليًا إلى ذلك.

ابدأ بتحديد الطبقة التي تفشل

خطأ شائع في استكشاف الأخطاء هو التعامل مع كل مهلة كأنها نفس المشكلة. الخادم المنزلي الذي يظهر غير متصل في tailnet يختلف عن الخادم الذي يستجيب لأمر ping الخاص بـ Tailscale لكنه يرفض اتصال SSH أو الويب.

يوفر Tailscale مسار الشبكة الخاصة بين الأجهزة، لكن الخدمة النهائية تعتمد على نظام تشغيل الخادم، وجدار الحماية، ومنفذ الاستماع، وتكوين التطبيق، وشبكة Docker، وسياسة الوصول. قد يؤدي إصلاح الطبقة الخاطئة إلى مشاكل إضافية دون استعادة الاتصال.

قبل تغيير أي شيء، دوّن العَرَض الدقيق. تحقق مما إذا كان الخادم يظهر متصلًا، وما إذا كان عنوان IP الخاص بـ Tailscale يستجيب، وما إذا كان اسم MagicDNS يحل، وما إذا كان منفذ التطبيق المحدد يقبل الاتصال.

تأكد من أن كلا العقدتين في Tailscale متصلتان

ابدأ بالجهازين المشاركين في الاتصال. يجب أن يكون الكمبيوتر المحمول أو الهاتف البعيد متصلًا بشبكة tailnet، ويجب أن يكون الخادم المنزلي متصلًا أيضًا تحت الحساب أو العلامة أو هوية الجهاز المتوقعة.

على خادم Linux، تحقق من خدمة Tailscale وقم بتشغيل حالة tailscale. على أنظمة سطح المكتب، تحقق من أن العميل متصل وليس متوقفًا مؤقتًا أو مسجلاً الخروج أو في انتظار المصادقة. لا يمكن إصلاح الخادم الذي فشل في بدء Tailscale بعد إعادة التشغيل عن طريق تغيير DNS أو منافذ التطبيق.

تحقق أيضًا مما إذا كان الخادم يظهر تحت اسم الجهاز المتوقع وعنوان IP الخاص بـ Tailscale. إذا كانت العقدة غير متصلة، أصلح الخدمة، حالة تسجيل الدخول، سلوك بدء النظام، أو إصدار العميل قبل استكشاف أي شيء فوق طبقة الشبكة.

استخدم عنوان IP الخام لـ Tailscale قبل اختبار اسم المضيف

يضيف اسم المضيف حل DNS إلى مسار الاتصال. إذا بدأت باسم خادم مثل خادم-المنزل أو جهاز-nas، لا يمكنك تحديد ما إذا كان الفشل ناتجًا عن الشبكة أو حل الأسماء على الفور.

ابحث عن عنوان IPv4 الخاص بـ Tailscale للخادم، عادة في نطاق 100.x.x.x، وجرب هذا العنوان مباشرة. عندما تعقد مسارات LAN أو عقد الخروج أو الشبكات الفرعية المتداخلة المسار، يكون من المفيد بشكل خاص اختبار عنوان IP الخاص بـ Tailscale قبل عنوان LAN الخاص.

إذا عمل عنوان IP الخام لكن اسم المضيف لم يعمل، فمن المحتمل أن يكون الاتصال الأساسي بالعقدة سليمًا. انتقل إلى MagicDNS وإعدادات DNS للعميل بدلاً من إعادة تثبيت Tailscale أو تغيير جهاز التوجيه.

إذا عمل عنوان IP لكن الاسم فشل، تحقق من MagicDNS

يتيح MagicDNS للأجهزة استخدام أسماء أجهزة قابلة للقراءة بدلاً من حفظ عناوين IP الخاصة بـ Tailscale. عندما يعمل، يكون الجهاز المسمى خادم-المنزل يمكن الوصول إليه من خلال هذا الاسم من جهاز آخر في نفس شبكة tailnet.

تُنشئ هذه الميزة أسماء أجهزة تلقائية داخل شبكة tailnet، لكن النجاح في الترجمة يعتمد على اتصال الجهاز وقبول العميل لإعدادات DNS الخاصة بالشبكة. يمكن أن تتداخل عوامل تصفية DNS المحلية، أدوات أمان المؤسسات، المحللات المخصصة، أو السجلات المخزنة القديمة.

قارن اسم المضيف القصير، الاسم الكامل لشبكة tailnet، وعنوان IP الخام لـ Tailscale. إذا فشلت الأسماء فقط، تحقق مما إذا كان MagicDNS مفعلاً، إذا تم إعادة تسمية الجهاز، وإذا كان منتج DNS آخر يتجاوز إعدادات المحلل.

فصل اتصال Tailscale عن اتصال التطبيق

الاتصال الناجح من عقدة إلى أخرى لا يثبت أن كل خدمة على الخادم يمكن الوصول إليها. قد تتمكن من اختبار ping على عنوان Tailscale بينما SSH أو Jellyfin أو لوحة التحكم أو SMB أو واجهة ويب Docker لا تستجيب.

هذا يعني عادةً أن مسار Tailscale موجود لكن طبقة التطبيق ترفض الاتصال أو مفقودة. قد تكون الخدمة متوقفة، تستمع على منفذ آخر، مرتبطة بواجهة خاطئة، محجوبة بواسطة جدار حماية الخادم، أو غير منشورة من الحاوية الخاصة بها.

اختبر الوجهة الدقيقة التي تحتاجها، مثل 100.x.x.x:22 لـ SSH أو http://100.x.x.x:8080 لخدمة ويب. إذا استجاب العقدة ولكن المنفذ لم يستجب، توقف عن استكشاف أخطاء MagicDNS و DERP حتى يتم التحقق من خدمة الخادم.

تحقق مما إذا كانت الخدمة تستمع على الواجهة الصحيحة

يمكن لتطبيق أن يعمل بشكل طبيعي على خادم المنزل ومع ذلك لا يمكن الوصول إليه من أي جهاز آخر. يحدث هذا عندما تستمع الخدمة فقط على 127.0.0.1، والتي تقبل الاتصالات من الخادم نفسه ولكن ليس عبر واجهات LAN أو Tailscale الخاصة به.

خدمة تستمع على 0.0.0.0 تقبل حركة IPv4 على جميع الواجهات المتاحة، بينما يمكن ربط الخدمة أيضًا صراحة بعنوان LAN الخاص بالخادم أو عنوان Tailscale. يعتمد الاختيار الصحيح على ما إذا كان يجب أن تكون الخدمة قابلة للوصول من LAN أو tailnet أو فقط من خلال وكيل عكسي محلي.

لا تغير تلقائيًا كل خدمة إلى 0.0.0.0. أكد مسار الوصول المقصود أولاً، ثم استخدم قواعد جدار الحماية والمصادقة على التطبيق لتحديد من يمكنه الوصول إلى المنفذ.

قد يمنع جدار حماية الخادم حركة مرور Tailscale

يمكن لخدمة أن تعمل عبر عنوان LAN الخاص بخادم المنزل ولكن تفشل عبر عنوان Tailscale الخاص به لأن نظام التشغيل يعامل واجهة Tailscale كمسار شبكة منفصل. قواعد LAN لا تنطبق دائمًا على حركة المرور القادمة عبر tailscale0.

قد تستخدم أنظمة Linux أدوات مثل UFW أو firewalld أو iptables أو nftables. قد يصنف Windows محول Tailscale بشكل مختلف عن شبكة LAN المنزلية. يمكن لجدران الحماية الأوسع للشبكة أيضًا منع الاتصالات المباشرة عبر UDP وإجبار حركة المرور على المسارات المعاد توجيهها. الفحص المهم هو ما إذا كان جدار الحماية يسمح بمسار الاتصال المقصود لـ Tailscale.

لا تقم بتعطيل جدار الحماية بالكامل كحل دائم. اسمح فقط بمنفذ الخدمة المطلوب من واجهة Tailscale، أو عناوين Tailscale المختارة، أو سياسة tailnet المناسبة. ثم أعد اختبار التطبيق مباشرة.

تحقق من سياسات الوصول، والتصاريح، والعلامات، وهوية الجهاز

إذا كان بإمكان جهاز Tailscale واحد الوصول إلى خادم المنزل بينما لا يستطيع جهاز آخر، فقد يكون الاختلاف سياسة مقصودة وليس فشلًا في الشبكة. يمكن أن يعتمد الوصول على المستخدم، وجهاز المصدر، وعلامة الوجهة، والبروتوكول، والمنفذ.

قد لا يقبل الخادم الموسوم للوصول إلى البنية التحتية حركة المرور من جهاز شخصي ما لم تسمح السياسة بهذا الجمع. قاعدة تسمح بـ SSH لا تعني بالضرورة السماح بلوحة التحكم على الويب على منفذ آخر، وقد يكون للجهاز المشترك أذونات مختلفة عن الجهاز المملوك لنفس المستخدم.

راجع هوية المصدر، وهوية الوجهة، وعلامات الخادم، والمنفذ المطلوب معًا. يمكن أن تساعد قاعدة عامة مؤقتة واسعة في عزل مشكلة السياسة، ولكن استبدلها بأضيق قاعدة صحيحة بعد الاختبار.

الخادم المنزلي المباشر لا يحتاج إلى موجه شبكة فرعية

إذا تم تثبيت Tailscale مباشرة على خادم المنزل، فاستخدم عنوان IP الخاص بـ Tailscale للخادم أو اسم MagicDNS الخاص به. لا يلزم وجود موجه شبكة فرعية للوصول إلى تلك الآلة.

تحل أجهزة التوجيه الشبكية مشكلة مختلفة: فهي توفر الوصول إلى الأجهزة التي لا تشغل Tailscale بنفسها، مثل الطابعة، الكاميرا، NAS القديم، جهاز المنزل الذكي، أو جهاز آخر على شبكة LAN المنزلية.

إضافة توجيه الشبكات الفرعية إلى مشكلة عقدة مباشرة بسيطة يخلق المزيد من الأماكن التي قد يفشل فيها الاتصال. أثبت أولاً أن عميل Tailscale على خادم المنزل يمكن الوصول إليه. لا تحل مشاكل مسارات LAN المعلنة إلا عندما يكون الهدف الفعلي خلف ذلك الخادم.

توجيه الشبكات الفرعية يتطلب سلسلة توجيه كاملة

عندما يكون الهدف جهاز LAN بدون Tailscale، يجب على جهاز التوجيه الشبكي أن يفعل أكثر من مجرد الظهور على الإنترنت. عليه استقبال حركة المرور من tailnet، توجيهها إلى شبكة LAN المنزلية، والسماح للرد بالعودة.

عادةً ما يتطلب الإعداد العامل تفعيل توجيه IP على جهاز التوجيه، الإعلان عن مسارات الشبكة الفرعية، الموافقة على المسارات، مطابقة ضوابط الوصول، وقبول المسارات من جانب العميل حيثما يلزم. الهدف هو الإعلان عن شبكة فرعية خاصة عبر بوابة حتى تتمكن أجهزة tailnet من الوصول إلى الأجهزة التي لا تشغل العميل.

إذا كان المسار مرئيًا لكن حركة المرور تفشل، تحقق من كل مرحلة على حدة. تأكد من الإعلان عن الشبكة الفرعية الصحيحة، تحقق من الموافقة عليها، افحص جدار الحماية الخاص بالتوجيه، وتأكد من أن جهاز LAN لديه مسار عودة صالح.

الشبكات الفرعية الخاصة المتداخلة يمكن أن توجه حركة المرور في الاتجاه الخاطئ

تعيد العديد من شبكات المنازل والمكاتب والفنادق استخدام عناوين مثل 192.168.1.0/24. إذا كانت شبكة Wi-Fi الحالية وشبكة المنزل الفرعية تستخدمان نفس النطاق، فقد يعامل نظام التشغيل الوجهة كمحلية بدلاً من إرسالها عبر Tailscale.

هذا يخلق عرضًا محيرًا: عنوان IP المباشر لـ Tailscale الخاص بالخادم يعمل، لكن عنوان IP الخاص بشبكة LAN المنزلية لا يعمل. قد يكون الطلب موجهًا إلى الشبكة الحالية بدلاً من جهاز التوجيه الخاص بالشبكة الفرعية البعيدة.

استخدم عنوان IP الخاص بـ Tailscale للجهاز الهدف كلما أمكن ذلك. إذا كان الوصول إلى الشبكة الفرعية ضروريًا، فكر في تغيير إحدى شبكات LAN إلى نطاق خاص أقل شيوعًا أو تطبيق تصميم توجيه يتعامل مع الشبكات المتداخلة بشكل متعمد.

يمكن لعقدة الخروج تغيير الوصول إلى LAN الحالي

إذا كان جهاز العميل يستخدم عقدة خروج Tailscale، فإن اختيار المسار يختلف عن اتصال tailnet العادي. قد يتم حظر الوصول إلى أجهزة LAN القريبة ما لم يُسمح صراحةً بالوصول إلى الشبكة المحلية.

هذا مهم عند استكشاف الأخطاء من كمبيوتر محمول متصل بشبكة Wi-Fi في فندق أو مكتب أو منزل أثناء استخدام عقدة خروج أيضًا. قد يأتي فشل الوصول إلى عنوان LAN خاص من سلوك عقدة الخروج وليس من الخادم المنزلي.

اختبر بدون عقدة الخروج، أو فعّل الوصول إلى LAN فقط عندما تثق في الشبكة المحلية. لا تفعل الوصول المحلي الواسع تلقائيًا على شبكات Wi-Fi عامة غير معروفة.

يضيف Docker حدود منفذ وواجهة أخرى

قد يعمل خدمة مضيف مثل SSH عبر Tailscale بينما يفشل تطبيق Docker على نفس الخادم. يشير ذلك عادةً إلى شبكات الحاويات بدلاً من اتصال العقدة.

تحقق مما إذا كانت الحاوية تعمل، وما إذا كان التطبيق يستمع داخل الحاوية، وما إذا كان منفذه منشورًا إلى المضيف. يمكن أن يكون تعيين Compose مثل 8080:80 يكشف منفذ الحاوية 80 عبر منفذ المضيف 8080، بينما المنفذ المرتبط فقط بـ 127.0.0.1 قد تظل غير قابلة للوصول عبر عنوان IP الخاص بـ Tailscale.

تحقق أيضًا من مسارات الوكيل العكسي، شبكات المضيف، قواعد جدار حماية Docker، وما إذا كان التطبيق نفسه يسمح بالاتصالات من عناوين غير LAN. اختبر منفذ المضيف مباشرة قبل تصحيح أخطاء المجالات أو الشهادات على مستوى أعلى.

عادةً ما يفسر DERP البطء أكثر من الفشل الكامل

تحاول Tailscale إنشاء اتصالات مباشرة بين الأجهزة. عندما تمنع سلوكيات NAT أو قيود جدار الحماية ذلك، يمكنها استخدام مسار ترحيل بدلاً من ذلك.

يوفر DERP تراجع ترحيل مشفر عند فشل الاتصال المباشر. يقوم الترحيل بإعادة توجيه حركة المرور المشفرة بالفعل ويمكنه ربط الأجهزة عبر تركيبات صعبة من IPv4 وIPv6 وNAT وجدار الحماية.

غالبًا ما يعمل مسار DERP مع تأخير أكبر أو معدل نقل أقل، لذا فهو مشتبه به قوي عندما يشعر SSH بالتباطؤ أو تكون عمليات نقل الملفات بطيئة. إذا لم يعمل الاتصال على الإطلاق، تحقق أولاً من حالة العقدة، سياسة الوصول، جدار الحماية المحلي، منفذ التطبيق، وعنوان الربط.

استخدم تشخيص الاتصال قبل تغيير جهاز التوجيه

أوامر مثل أمر ping في Tailscale ساعد في فصل مسار العقدة عن مسار التطبيق. النتيجة الناجحة تثبت أكثر من علامة تبويب متصفح فاشلة لأنها تختبر الاتصال دون الاعتماد على منفذ التطبيق أو الوكيل أو الشهادة.

tailscale netcheck يمكن أن تساعد في إظهار توفر UDP، سلوك NAT، اتصال IPv4 أو IPv6، ومناطق الترحيل القريبة. تكون هذه النتائج أكثر فائدة عندما يعمل الاتصال فقط عبر ترحيل أو يتغير بين الشبكات.

لا تبدأ بإضافة إعادة توجيه منفذ عام إلى راوتر المنزل. تم تصميم Tailscale للعمل دون كشف منافذ تطبيق خادم المنزل مباشرة على الإنترنت. يجب أن تستجيب تغييرات الراوتر لمشكلة مسار مؤكدة، وليس لتحل محل خطوات التشخيص السابقة.

أعد التشغيل والتحديث فقط بعد أن تعرف الطبقة الفاشلة

إعادة تشغيل Tailscale يمكن أن تستعيد خدمة خادمة فاشلة أو حالة عميل قديمة، لكن إعادة التشغيل المتكررة ليست تشخيصًا. إذا عاد نفس الفشل بعد كل إعادة تشغيل، فمن المحتمل أن تكون المشكلة الأساسية في تكوين بدء التشغيل، سياسة جدار الحماية، التوجيه، أو ربط التطبيق.

تأكد من أن خادم المنزل يبدأ Tailscale بدون تسجيل دخول تفاعلي على سطح المكتب ويظل متصلًا بعد إعادة التشغيل. قارن أيضًا إصدارات العملاء إذا تصرف جهاز واحد بشكل مختلف عن بقية الشبكة.

بعد التحديث أو إعادة التشغيل، كرر نفس الاختبارات بنفس الترتيب: حالة العقدة، عنوان IP الخام، اسم المضيف، أمر ping في Tailscale، ومنفذ التطبيق. يظهر تسلسل الاختبار المتسق أي طبقة تغيرت فعليًا.

اتبع ترتيب استكشاف الأخطاء وإصلاحها واحدًا

أسرع مسار هو الانتقال من عقدة Tailscale نحو التطبيق. لا تقم بتعديل DNS، مسارات الشبكة الفرعية، قواعد جدار الحماية، وشبكة Docker في نفس الوقت.

أولاً تأكد من أن كلا العقدتين متصلتان بالإنترنت. ثم اختبر عنوان IP الخام لـ Tailscale، يليه اسم MagicDNS. اختبر مسار العقدة، ثم منفذ التطبيق. فقط بعد هذه الفحوصات يجب أن تحقق في جدار حماية الخادم، عنوان الربط، سياسة الوصول، تعيين Docker، أو توجيه الشبكة الفرعية.

هذا الترتيب يمنع توقف الخدمة البسيطة من أن يتحول إلى مشروع توجيه معقد. يجب أن يجيب كل اختبار على سؤال واحد قبل الانتقال إلى الطبقة التالية.

النتيجة النهائية

عندما لا يتمكن Tailscale من الوصول إلى خادم المنزل الخاص بك، ابدأ بالتمييز الأبسط: هل يمكن للعقدتين في Tailscale التواصل، وهل يمكن للتطبيق قبول الحركة؟ تأكد من أن كلتا العقدتين متصلتان بالإنترنت، اختبر عنوان IP الخام لـ Tailscale، ثم اختبر اسم MagicDNS ورقم منفذ الخدمة الدقيق.

إذا كان مسار العقدة يعمل لكن التطبيق لا يعمل، ركز على جدار حماية الخادم، وواجهة الاستماع، وإعدادات التطبيق، وتعيين منفذ Docker، وسياسة الوصول. إذا لم يكن الهدف يشغل Tailscale، فانتقل إلى تكوين موجه الشبكة الفرعية، والموافقة على المسارات، وإعادة توجيه IP، وفحص الشبكات الفرعية المتداخلة.

عادةً ما تفسر مسارات ترحيل DERP الأداء الأبطأ بدلاً من الفشل الكامل. اختبار متسق طبقة بطبقة أكثر فعالية من إعادة تثبيت Tailscale، أو تعطيل جدار الحماية، أو إضافة إعادة توجيه منفذ عام دون معرفة مكان توقف الاتصال.

الأسئلة الشائعة

لماذا يمكنني إرسال طلب ping إلى خادم Tailscale الخاص بي ولكن لا يمكنني فتح واجهة الويب الخاصة به؟

الاتصال بين العقد يعمل، لكن خدمة الويب قد تكون متوقفة، أو تستمع على منفذ آخر، أو مرتبطة فقط بـ localhost، أو محجوبة بواسطة جدار حماية الخادم، أو غير منشورة من حاوية Docker الخاصة بها.

لماذا يعمل عنوان IP الخاص بـ Tailscale ولكن اسم الخادم لا يعمل؟

يشير هذا إلى مشكلة في MagicDNS أو تكوين DNS آخر. تحقق مما إذا كان MagicDNS مفعلاً، وما إذا تم تغيير اسم الجهاز، وما إذا كان محلل DNS آخر يتجاوز إعدادات Tailscale.

هل أحتاج إلى موجه شبكة فرعية للوصول إلى خادم المنزل الخاص بي؟

لا، عندما يكون Tailscale مثبتًا مباشرة على ذلك الخادم. استخدم عنوان IP الخاص بـ Tailscale أو اسم MagicDNS الخاص به. يلزم موجه شبكة فرعية للوصول إلى أجهزة LAN الأخرى التي لا تشغل Tailscale.

هل يمكن لجدار الحماية حظر Tailscale حتى عندما تكون العقدة متصلة بالإنترنت؟

نعم. يمكن لعميل Tailscale الاتصال بشبكة tailnet بينما لا يزال جدار حماية نظام التشغيل يمنع وصول SSH أو الويب أو SMB أو منفذ تطبيق آخر عبر واجهة Tailscale.

هل يعني اتصال DERP أن Tailscale معطل؟

لا. DERP هو حل احتياطي مشفر عندما لا يمكن إنشاء اتصال مباشر. قد يضيف تأخيرًا أو يقلل من معدل النقل، لكنه لا يزال يوفر الاتصال بين الأجهزة.

لماذا يمكنني الوصول إلى الخادم ولكن ليس إلى جهاز آخر على شبكة LAN المنزلية الخاصة بي؟

الخادم هو عقدة Tailscale مباشرة، بينما يحتاج الجهاز الآخر إلى موجه شبكة فرعية. تحقق من إعادة توجيه IP، والمسارات المعلنة، والموافقة على المسارات، وقواعد الوصول، ومسار العودة لجهاز LAN.

هل يمكن أن تتسبب الشبكات الفرعية المنزلية والبعيدة المتداخلة في تعطل وصول Tailscale؟

نعم. إذا كان كلا الموقعين يستخدمان نفس الشبكة الفرعية الخاصة، فقد يرسل العميل حركة المرور إلى شبكة LAN الحالية بدلاً من مسار الشبكة الفرعية البعيدة. يُفضل استخدام عنوان IP الخاص بـ Tailscale للهدف أو تغيير نطاق عناوين إحدى الشبكات.

هل يجب أن أفتح المنافذ على جهاز التوجيه الخاص بي لإصلاح Tailscale؟

عادة لا. قم أولاً بتأكيد حالة العقدة، وسلوك جدار الحماية، وربط التطبيق، وسياسة الوصول، وما إذا كان الاتصال مباشرًا أو معاد توجيهه. إعادة توجيه منفذ التطبيق علنًا ليست بديلاً عن العثور على سبب فشل Tailscale الفعلي.