چرا کلاینت Tailscale در لینوکس مسیرهای زیرشبکه‌ی اعلام‌شده را نادیده می‌گیرد

روی لپ‌تاپ لینوکس هستید، tailscale status سایر ماشین‌ها را فهرست می‌کند و NAS روی 10.80.0.25 هنوز به پایان زمان می‌رسد. tailnet سالم است، روتر زیرشبکه برخط است و هیچ‌چیز در خروجی کلاینت نمی‌گوید چرا LAN پشت آن در دسترس نیست. مسیر زیر از همان نشانه به بیرون حرکت می‌کند: پرچم روی این کلاینت، سپس اعلام روی روتر، سپس تأیید، سپس سیاست و تنها بعد از آن خود مقصد. هر دریچه با همان پایان زمان شکست می‌خورد، پس ترتیب از دستورها مهم‌تر است.

کلاینت لینوکس از نصب چه چیزی سر باز می‌زند

کلاینت‌های Tailscale در لینوکس مسیرهای زیرشبکه‌ی اعلام‌شده را نمی‌پذیرند مگر اینکه از آن‌ها بخواهید. بدون این تنظیم، کلاینت به tailnet می‌پیوندد و به نشانی‌های همتا می‌رسد، در حالی که هر پیشوندی که روتر اعلام می‌کند بی‌استفاده می‌ماند. مقدار پیش‌فرض عمدی است و همین باعث می‌شود نشانه شبیه روتر خراب باشد نه تصمیم محلی.

دو چیز جداگانه اینجا مسیریابی نامیده می‌شود و تنها یکی از آن‌ها مال شماست. روتر پیشوندی را در tailnet اعلام می‌کند؛ ماشین شما تصمیم می‌گیرد آن را نصب کند یا نه. شکست در هر کدام همان پایان زمان را تولید می‌کند، پس حدس زدن یک بعدازظهر را تلف می‌کند. پیش از ویرایش هر چیزی پیدا کنید کدام سمت امتناع می‌کند.

پذیرش مسیر را برای این ماشین روشن کنید

ترجیح را روی کلاینت تنظیم کنید و بعد ببینید چه چیزی تغییر کرده، نه اینکه فرض کنید دستور اعمال شده است. شکل کنونی تنظیم را بدون تکرار جریان ورود اعمال می‌کند، و این وقتی در میانه‌ی نشست هستید مهم است.

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

Tailscale مسیرهای پذیرفته‌شده را در جدول خودش در لینوکس نصب می‌کند، بنابراین پیشوندی که در جدول 52 ظاهر شود شاهد مستقیم نصب اعلام توسط این کلاینت است. اگر محدوده‌ی شما در آن جدول نیست، متوقف شوید: مشکل محلی است و هیچ کاری روی روتر آن را تغییر نمی‌دهد.

کلاینت‌های قدیمی‌تر همان ترجیح را به‌صورت پرچمی روی دستور ورود ارائه می‌دهند، پس sudo tailscale up --accept-routes جایگزین است وقتی tailscale set وجود ندارد. آن را به‌جای ویرایش دستی مسیرها به کار ببرید، زیرا سرویس‌دهنده جدول خودش را بازنویسی می‌کند و ویرایش شما در اتصال بعدی ناپدید می‌شود. پیش از کپی دستوری از نوشته‌ای قدیمی نسخه را بررسی کنید.

اعلام و تأیید را جداگانه بررسی کنید

روی روتر زیرشبکه پیشوند باید اعلام شود و هسته باید بسته‌ها را میان واسط‌ها هدایت کند. اعلام بدون هدایت مسیری تأییدشده به شما می‌دهد که ترافیک را بی‌صدا دور می‌ریزد، و این رایج‌ترین پیکربندی نیمه‌کاره است.

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

پیشوند اعلام‌شده را با نشانی‌ای که واقعاً می‌خواهید به آن برسید، حرف به حرف مقایسه کنید. روتری که 10.70.0.0/24 را اعلام می‌کند چیزی درباره‌ی NAS روی 10.80.0.25 نمی‌گوید و ناسازگاری در هیچ خروجی وضعیتی دیده نمی‌شود، چون هر دو عدد به یک اندازه باورپذیر به نظر می‌رسند. بیشتر گزارش‌های مسیر خراب همین‌جا پایان می‌یابد. پیش از دست زدن به هر چیز پایین‌دست، اعلام را درست کنید.

تأیید دریچه‌ی بعدی است و وقتی روتر از پوسته پیکربندی شده باشد آسان از قلم می‌افتد. اعلام باید برای آن دستگاه در کنسول مدیریت فعال شود پیش از آنکه ماشین‌های دیگر بتوانند از آن استفاده کنند. پذیرش مسیر روی کلاینت چیزی را تأیید نمی‌کند و هیچ قاعده‌ی دسترسی را نقض نمی‌کند.

پیش از نام میزبان، نشانی خصوصی را بیازمایید

اتصال موفق به نشانی tailnet خود روتر ثابت می‌کند tailnet کار می‌کند، چیزی که از قبل می‌دانستید. آزمون سودمند همان سرویسی است که واقعاً نیاز دارید، اول روی نشانی خصوصی، تا شکست DNS نتواند خود را شکست مسیریابی جا بزند.

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

اگر نشانی پاسخ می‌دهد و نام میزبان نه، مشکل تفکیک نام دارید و باید دست از برخورد با آن به‌عنوان مشکل مسیر بردارید. اگر هیچ‌کدام پاسخ نمی‌دهد، یک بخش عقب بروید و تأیید کنید اعلام نشانی را پوشش می‌دهد. دو شکست از دید برنامه یکسان به نظر می‌رسند و در جاهای متفاوتی رفع می‌شوند.

یک بررسی محلی پیش از سرزنش tailnet ارزش دارد. وقتی LAN کنونی شما همان پیشوند زیرشبکه‌ی دور را به کار می‌برد، هسته مسیر مستقیم متصل را ترجیح می‌دهد و ترافیک هرگز ماشین را ترک نمی‌کند؛ این همان چیزی است که وقتی خانه و دفتر هر دو 192.168.1.0/24 را انتخاب کنند رخ می‌دهد.

چرا پرچم کلاینت تنظیم روتر نیست

این‌ها نقش‌های متفاوت با نیازهای متفاوت‌اند و کپی پرچم کلاینت روی روتر همان راهی است که یک tailnet کارآمد حلقه پیدا می‌کند. ماشینی که مسیر اعلام می‌کند به هدایت، قواعد دیوار آتش که ترافیک هدایت‌شده را مجاز می‌کنند و تصمیمی درباره‌ی پیشوندهایی که اعلام می‌کند نیاز دارد. هیچ‌یک از این‌ها از --accept-routes برنمی‌آید.

مستندات روتر زیرشبکه هشدار می‌دهد که پذیرش مسیر را روی روترهای افزونه‌ای که یک پیشوند را اعلام می‌کنند فعال نکنید، زیرا گره‌ی آماده‌به‌کار می‌تواند ترافیکی را که از قبل محلی است از گره‌ی فعال بیرون بفرستد. اگر جفت HA دارید، آن را محدودیت طراحی بدانید نه پانویس، و پیش از تأیید روی هر دو تصمیم بگیرید کدام گره مالک پیشوند است. روی یک روتر، همان هشدار یادآور می‌شود که پذیرش متعلق به کلاینت‌هاست نه ماشینی که اعلام می‌کند. بنویسید کدام دریچه بسته بود.

برای یک کلاینت معمولی، توالی با آزمون برنامه‌ای پایان می‌یابد که در آغاز شکست خورد. برای روتر، هدایت، اعلام، تأیید و دیوار آتش را به همان ترتیب مرور کنید، زیرا نخستین مورد غایب دقیقاً همان پایان زمانی را تولید می‌کند که با آن شروع کردید.