چرا مسیر زیرشبکه تأییدشده در 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 کامل برای اینکه یک برنامه کار کند همان راهی است که یک درخواست باریک به مجوزی گسترده تبدیل می‌شود که بعداً هیچ‌کس جرئت حذفش را ندارد.

اگر هدف خروج به اینترنت بود نه یک زیرشبکه خصوصی، مؤلفه درست یک گره خروج است، نه مسیریاب زیرشبکه، و سیاست و مسیریابی بر همین اساس تفاوت می‌کنند. پیش از گستردن یک مجوز آن تصمیم را بررسی کنید. گره خروج مسیر پیش‌فرض را تغییر می‌دهد؛ مسیریاب زیرشبکه فقط یک پیشوند اعلام می‌کند.