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

قانون چه چیزی را تثبیت می‌کند و DNS چه چیزی برمی‌گرداند

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

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

سه راهی که مطابقت می‌شکند

مورد آشکار یک سرویس جابه‌جاشده است: اپراتور نشانی جدیدی به آن داد، DNS دنبال کرد و استثنا دنبال نکرد. دومی یک خانواده نشانی است که قانون هرگز پوشش نداده، که وقتی رخ می‌دهد که یک نام شروع به برگرداندن رکوردهای AAAA کند که یک استثنای فقط IPv4 آن‌ها را نادیده می‌گیرد. سومی تفاوت resolver است: یک دید داخلی و یک دید عمومی می‌توانند برای همان نام نشانی‌های متفاوت برگردانند، پس نشانی‌ای که برنامه شما استفاده می‌کند همانی نیست که با آن آزمایش کردید.

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

مقصدی را بخوانید که برنامه واقعاً استفاده می‌کند

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

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

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

مکانیزم را تعمیر کنید، نه نشانه را

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

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

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

هر دو نیمه قصد را بررسی کنید

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

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

نشانی جدید، مکانیزمی که انتخاب کردید و تاریخ را ثبت کنید. همان یادداشت است که مانع می‌شود نفر بعدی نتیجه بگیرد که VPN پیکربندی خودش را تصادفی نادیده گرفته است.

مقالات مرتبط