ترافیک یکطرفه پس از غیرفعال کردن SNAT زیرشبکه Tailscale
SNAT را روی یک مسیریاب زیرشبکه Tailscale خاموش کنید و پاسخها دیگر نمیرسند. نشانی مبدأ واقعی باقی میماند، بنابراین LAN به مسیر بازگشتی به 100.64.0.0/10 نیاز دارد.
NAT مبدأ را روی یک مسیریاب زیرشبکه Tailscale خاموش کنید؛ تونل همچنان کار میکند در حالی که اتصالهای عبوری از آن متوقف میشوند. درخواستها با نشانی overlay خودِ کلاینت دوردست به مقصد میرسند، که دقیقاً هدف این تغییر است، و پاسخها اکنون به مسیری نیاز دارند که LAN هرگز نباید میدانست. بدون آن مسیر، بستهها فرود میآیند، پاسخها از دروازه معمولی خارج میشوند و خرابی بهصورت مشکلی در دیوار آتش ظاهر میشود که هیچ قاعدهای آن را توضیح نمیدهد. تونل سالم است؛ مسیر بازگشت غایب است.
SNAT چه چیزی را پنهان میکرد
با فعال بودن SNAT، مسیریاب پیش از ارسال به زیرشبکه، نشانی مبدأ را به نشانی LAN خودش بازنویسی میکند، بنابراین مقصد به میزبانی پاسخ میدهد که از قبل راه رسیدن به آن را میداند و چیز دیگری نیاز به پیکربندی ندارد. غیرفعال کردن آن مبدأ اصلی را حفظ میکند و مقصد آنگاه نشانیای در محدوده overlay میبیند، نه همسایهای روی سیم خودش. آن نشانی واقعی و در سراسر tailnet قابل مسیریابی است، اما از LAN از طریق دروازه پیشفرض قابل دسترسی نیست. کلید مستندشده --snat-subnet-routes=false است که روی خود مسیریاب زیرشبکه Linux اعمال میشود.
این یک تنظیم دائمی است نه کلیدی برای هر بسته، بنابراین مسیر بازگشت باید برای هر شبکه مقصدی که آن مسیریاب سرویس میدهد وجود داشته باشد. همین است که تغییر را به تصمیمی برای استقرار تبدیل میکند، نه یک کادر انتخاب. هر چیزی که آن مسیریاب سرویس میدهد، این الزام را در همان لحظه به ارث میبرد.
مسیر بازگشت کجا میتواند باشد
سه جایگاه رایج است و آنها در گستره تفاوت دارند، نه در درستی. مسیر ثابت روی میزبان مقصد مستقیمترین و کمترین مقیاسپذیر است، چون هر دستگاه نسخه خودش را نیاز دارد. جدول مسیریابی در VPC یا در مسیریاب سایت، کل شبکه را یکجا پوشش میدهد، و گزینه DHCP که مسیرهای ثابت بیکلاس را حمل میکند بهطور خودکار به کلاینتها میرسد اما روی دستگاههایی که آن را نادیده میگیرند بیصدا شکست میخورد.
ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5
هر جایگاهی که انتخاب کنید، گام بعدی نشانی LAN مسیریاب است و هرگز نشانی tailnet آن نیست. میزبان LAN تا این مسیر را نداشته باشد نمیتواند به overlay برسد، بنابراین گام بعدی داخل overlay دایرهای است و بسته را به هیچجا نمیفرستد. همین یک اشتباه بیشتر پیکربندیهایی را توضیح میدهد که درست به نظر میرسند و باز هم شکست میخورند، و از هر بررسیای که فقط جدول خود مسیریاب را میخواند جان سالم به در میبرد. بنویسید از کدام جایگاه استفاده کردید، وگرنه نفر بعدی جایگاه اشتباه را آزمایش میکند.
خواندن خرابی بهعنوان ترافیک یکطرفه
نشانه آسانتر از علت شناخته میشود: سرویس روی خود مسیریاب پاسخ میدهد و از یک کلاینت دوردست ساکت میماند. یک ضبط روی مقصد نشان میدهد درخواستها میرسند و پاسخها خارج میشوند، که تا زمانی که توجه نکنید این پاسخها کجا میروند شبیه موفقیت است. آنها به سمت دروازه پیشفرض میروند، یعنی مسیر ورودی کار کرده و مسیر بازگشت نه.
بهجای آن روی مسیریاب ضبط کنید، چون هر دو جهت یک تبادل را میبیند و نشان میدهد آیا پاسخی هرگز رسیده است. اگر پاسخ روی مقصد ظاهر شود اما هرگز روی مسیریاب نه، مسیر در سمت مقصد غایب یا اشتباه است. اگر روی مسیریاب ظاهر شود و همانجا بایستد، مشکل جلوتر است و به بررسی دیگری تعلق دارد.
sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5
آیا نشانی واقعی ارزش یک مسیر را دارد
نگه داشتن SNAT هر زمان که شبکه مقصد قابل پیکربندی مجدد نباشد پاسخ سادهتر میماند، و هزینهاش این است که هر کلاینت در گزارشها و سیاست مقصد شبیه مسیریاب دیده میشود. خاموش کردن آن وقتی موجه است که یک برنامه به نشانی مبدأ واقعی نیاز داشته باشد یا سیاست شبکه باید کلاینتهایی را که یک مسیریاب را شریکاند از هم جدا کند. هر دو دلیل مشروعاند و هیچکدام رایگان نیست. سود باید ارزش نگهداری مسیر در هر شبکه مقصد را داشته باشد، بهعلاوه بازبینی دیوار آتش که در ادامه توضیح داده میشود.
برای یک LAN کوچک این معامله معمولاً میارزد، اما برای انبوهی از دستگاهها که نمیتوانند مسیر ثابت بگیرند معمولاً نمیارزد. تصمیم و دلیل را کنار پیکربندی مسیریاب ثبت کنید تا مدیر بعدی بداند کدام رفتار عمدی است. پیشفرضی که کسی ننوشته باشد از یک غفلت قابل تشخیص نیست.
دیوار آتش، ثبت گزارش و نقش دوگانه
هر قاعدهای که با نشانی LAN مسیریاب تطبیق میکرد اکنون با مبدأ دیگری تطبیق میکند، و این شامل قواعد اجازه و هر فیلد گزارشی است که مسیریاب را بهعنوان کلاینت ثبت میکرد. آن قواعد را پیش از نخستین آزمون بخوانید نه پس از نخستین شکست، چون قاعدهای که فقط نشانی مسیریاب را مجاز میکند مبدأ جدید را کاملاً مسدود میکند. جایگزین را به کلاینتها و درگاههایی که به آن نیاز دارند محدود کنید، سپس تأیید کنید که بیصدا کل tailnet را نمیپذیرد.
sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'
یک گره که همزمان بهعنوان گره خروجی و مسیریاب زیرشبکه کار میکند ترکیبی مستند است که پس از غیرفعال شدن SNAT زیرشبکه میتواند ترافیک بالادستی را بیندازد. جدا کردن این نقشها روی گرههای مختلف آن هشدار را برمیدارد و به هر مسیر و سیاست دیوار آتش یک مالک میدهد. اگر نقشها باید کنار هم بمانند، این رفتار را انتظار داشته باشید و پیش از سرزنش کلاینت آن را بیازمایید. مسیر، تنظیم کلید و تخصیص نقش را در یک یادداشت نگه دارید، چون وقتی اتصال بعدی شکست بخورد با هم خوانده میشوند.