لماذا تنتهي مهلة مسار شبكة فرعية معتمد في Tailscale رغم اعتماده

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

أربع مراحل، فشل واحد

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

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

على Linux، للمرحلة الثالثة أيضاً سلوك افتراضي يفاجئ الناس: قبول مسارات الشبكات الفرعية اختياري. تقبل عدة عملاء بواجهة رسومية المسارات المعلنة افتراضياً، لذا يمكن لأسطول مختلط أن يُظهر جهازاً واحداً فاشلاً بينما يعمل الباقي.

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

افحص المسار حيث يعمل العميل

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

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

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

لقبول المسارات على Linux، أعد الاتصال بالعلامة بدلاً من افتراض أنها مضبوطة: tailscale up --accept-routes. العميل الذي انضم بعلامات مختلفة يحتفظ بها حتى تُغيَّر، فافحص الإعداد الحالي قبل إضافة آخر. إعادة تشغيل الأمر الأول بعد التغيير يجب أن تُظهر المسار في الجدول.

أثبت إعادة التوجيه ومسار العودة

الاعتماد لا يضبط الموجّه لإعادة توجيه الحزم، ولا يرتب الرد. كلاهما شأن على مستوى المضيف في جانب LAN لدى الموجّه. اختبرهما على الموجّه، لا على العميل.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

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

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

اقرأ قاعدة الوصول الخاصة بالمورد

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

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

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

الاسم الفاشل سؤال مختلف عن العنوان الفاشل؛ حلّ المضيف مباشرة قبل إلقاء اللوم على المسار. اكتب المنحة مقابل متطلب المورد الفعلي لا مقابل الشبكة الفرعية كلها. فتح /24 كاملة حتى تعمل تطبيقة واحدة هو كيف يتحول طلب ضيق إلى إذن واسع لا يجرؤ أحد لاحقاً على إزالته.

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