آیا کش مسیر VPN تغییر شما را پنهان می‌کند؟ سه چیز را بررسی کنید

پاک کردن کش مسیر اولین غریزه است وقتی تغییری اعمال نمی‌شود، و در لینوکس مدرن تلاشی بیهوده است: کش سراسری مسیرهای IPv4 سال‌ها پیش حذف شده، بنابراین ip route show cache چیزی چاپ نمی‌کند و چیزی برای پاک کردن نیست. وضعیتی که شما را فریب می‌دهد یک لایه بالاتر زندگی می‌کند: در یک سوکت، یک نگاشت NAT، یک resolver یا یک مدیر شبکه که پروفایل قدیمی را دوباره اعمال کرده است. سه پرسش این موارد را جدا می‌کند: آیا مسیر نادرست از یک جریان تازه می‌آید یا از یک اتصال قدیمی، آیا پلتفرم شما اصلاً مسیرها را کش می‌کند، و آیا وضعیت در مسیریابی است یا بالاتر از آن. پیش از بازنشانی یک رابط به آن‌ها پاسخ دهید.

بررسی یک: آیا مسیر قدیمی از یک جریان تازه می‌آید؟

اتصال برقرارشده مسیری را که با آن ساخته شده نگه می‌دارد. به همین دلیل یک نشست SSH روی تونل از تغییر جدول مسیریابی جان سالم به در می‌برد، در حالی که نشست جدید بی‌درنگ مسیر جدید را می‌گیرد، و به همین دلیل «تغییر هیچ کاری نکرد» اغلب یعنی «سوکت قدیمی هنوز آن را نگه داشته است». با یک فرایند جدید آزمایش کنید، نه با پنجره‌ای که از قبل باز است.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

دستور آخر آدرسی را چاپ می‌کند که اتصال جدید واقعاً به آن رسیده است، و این ارزان‌ترین راه دیدن مسیر واقعی بدون اعتماد به پنجره وضعیت است. آن را با آدرس مبدأیی مقایسه کنید که فضای نام یا رابط قرار بود استفاده کند.

اگر جریان تازه مسیر درست را بگیرد و قدیمی بازیابی نشود، نگاه کردن به مسیریابی را متوقف کنید. مسیر درست بود؛ نشست قدیمی بود.

بررسی دو: آیا پلتفرم شما اصلاً کش مسیر نگه می‌دارد؟

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

پلتفرم‌های دیگر متفاوت‌اند و کپی کردن توصیه‌ها دقیقاً اینجا خراب می‌شود. ویندوز کش مقصدی نگه می‌دارد که می‌توانید با netsh interface ip delete destinationcache پاک کنید. BSD و macOS جست‌وجوهای هر مقصد را از طریق route -n get نشان می‌دهند، و کش‌هایشان طبق برنامه خودشان منقضی می‌شوند. دستوری که روی یکی از این‌ها کار می‌کند در لینوکس هیچ کاری نمی‌کند، و به همین دلیل همان راه‌حل برای نیمی از کسانی که امتحانش می‌کنند شکست‌خورده به نظر می‌رسد.

جدول NAT یا conntrack کش مسیر نیست، هرچند همان نشانه را تولید می‌کند. جریانی که پیش از تغییر شما ترجمه شده ترجمه‌اش را نگه می‌دارد، و conntrack -L مدت‌ها پس از آنکه سیاست مسیریابی جلوتر رفته آن را نشان می‌دهد. این وضعیت کهنه است، اما پاک کردن مسیرها به آن دست نمی‌زند.

بررسی سه: آیا وضعیت در مسیریابی است یا بالاتر از آن؟

پیش از خواندن هر چیز دیگری جست‌وجوی کنونی را بخوانید: ip route get برای مقصد، سپس همان دستور با from و آدرس مبدأ، سپس ip rule show. اگر این سه با آنچه در نظر داشتید هم‌خوان باشد، مسیریابی لایه‌ای نیست که باید درست شود، و مشاهده کهنه از جای دیگری آمده است.

سه مظنون رایج بالاتر از مسیریابی می‌نشینند. یک مدیر شبکه می‌تواند ثانیه‌هایی پس از حذف یک مسیر، آن را از پروفایل ذخیره‌شده دوباره نصب کند، بنابراین به نظر می‌رسد تغییر شما برمی‌گردد؛ پیش از ویرایش دوباره جدول nmcli connection show --active و وضعیت واحد را بررسی کنید. کش resolver آدرس کهنه برمی‌گرداند، که تا وقتی همان نام را با ابزاری که کش را دور می‌زند نپرسید، مانند شکست مسیریابی به نظر می‌رسد. استخر اتصال یک برنامه سوکت کارآمدی به مقصد قدیمی نگه می‌دارد و هرگز از هسته تصمیم تازه نمی‌خواهد.

سه پاسخ چه نتیجه‌ای به شما می‌دهند

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

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

اگر واقعاً باید چیزی را پاک کنید، کوچک‌ترین چیزی را پاک کنید که با تشخیص می‌خواند: سوکت‌های یک فرایند، یک ورودی conntrack، کش resolver. سپس همان آزمون جریان تازه را تکرار کنید و بنویسید چه چیزی تغییر کرد.

سه وضعیت را در یادداشت‌هایتان جدا نگه دارید

پیکربندی ذخیره‌شده، جست‌وجوی کنونی و جریان مشاهده‌شده سه واقعیت متفاوت‌اند، و یکی کردن آن‌ها در «کش» همان چیزی است که بازتولید خطا را دشوار می‌کند. پروفایل یا واحدی که مالک مسیر است، خروجی ip route get، و مبدأ و مقصد اتصال واقعی را بنویسید.

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