مستندات تونل تقسیم‌شده به یک قاعده DNS در کنار هر مسیر نیاز دارد
مسیر بر اساس نشانی تصمیم می‌گیرد، resolver بر اساس نام. هر دو انتخابگر را برای هر جریان مستند کنید، هرکدام با یک آزمون، وگرنه یادداشت با جابه‌جایی DNS شکست می‌خورد.
یادداشت تونل تقسیم‌شده‌ای که می‌گوید "ترافیک دفتر از VPN عبور می‌کند" یک تصمیم را مستند کرده و سه تصمیم دیگر را تلویحاً پذیرفته است. در لایه بسته، جدول مسیریابی رابط را بر اساس نشانی مقصد انتخاب می‌کند؛ در لایه نام، resolver سرور را بر اساس پرس‌وجو انتخاب می‌کند، و این دو انتخاب مستقل از هم انجام می‌شوند. به همین دلیل یک پیشوند درست مستندشده هنوز می‌تواند ماشینی بسازد که یک نام داخلی را به نشانی عمومی تبدیل می‌کند، یا در حالی که مسیر بی‌عیب به نظر می‌رسد هیچ چیز را تبدیل نکند.
دو انتخابگر، یک تلاش برای اتصال
وقتی برنامه‌ای به files.corp.example متصل می‌شود، پیش از آنکه بسته‌ای وجود داشته باشد دو جست‌وجو رخ می‌دهد. resolver تصمیم می‌گیرد کدام سرور پرس‌وجو را دریافت کند، با استفاده از دامنه‌های جست‌وجو، دامنه‌های مسیریابی هر پیوند یا قاعده صریح پروفایل. سپس جدول مسیریابی تصمیم می‌گیرد نشانی حاصل کجا برود، با استفاده از بلندترین تطابق پیشوند با مقصد.
هیچ چیز آن دو تصمیم را به هم پیوند نمی‌دهد. یک ناحیه خصوصی می‌تواند با 10.20.4.11 پاسخ دهد در حالی که جدول مسیریابی 10.20.0.0/16 را به تونل می‌فرستد، و اتصال کار می‌کند. هر یک از این دو را برگردانید و به شکلی شکست می‌خورد که شبیه دیگری است: سیاست DNS درست به‌همراه مسیر مفقود نامی حل‌شده و یک وقفه می‌دهد، در حالی که مسیر درست به‌همراه resolver عمومی نشانی‌ای می‌دهد که پاکیزه به جای اشتباه مسیریابی می‌شود.
DNS با افق تقسیم‌شده این را تیزتر می‌کند. همان نام می‌تواند از resolver داخلی نشانی خصوصی و از resolver روبه‌اینترنت نشانی عمومی برگرداند، بنابراین یادداشتی که فقط پیشوند را ثبت می‌کند نمی‌تواند پیش‌بینی کند مشتری واقعاً از کدام نشانی استفاده خواهد کرد. مسیر resolver را بنویسید وگرنه نشانی یک حدس است.
یادداشت فقط درباره مسیر چه چیزی را جا می‌گذارد
سندی که فقط مسیر را ثبت کند برای رایج‌ترین خرابی تونل تقسیم‌شده بی‌فایده است: نام‌ها. کاربر گزارش می‌دهد که اینترانت بارگذاری نمی‌شود، تونل بالاست و پیشوند حاضر است. کسی که تیکت را برمی‌دارد هیچ سندی از اینکه کدام resolver باید پاسخ می‌داد ندارد، راهی برای تمایز پسوند جست‌وجوی اشتباه از سرور مسدود ندارد، و هیچ خط پایه‌ای برای مقایسه ندارد.
دومین جاافتادگی فهرست استثناهاست. طراحی تونل تقسیم‌شده به همان اندازه که با آنچه وارد تونل می‌شود تعریف می‌شود با آنچه بیرون می‌ماند نیز تعریف می‌شود، و بازه‌های مستثنی معمولاً نخستین چیزی هستند که می‌شکنند، زیرا یک مسیر محلی مشخص‌تر یا یک فیلتر سمت مشتری می‌تواند بدون دست زدن به پروفایل نیت را نقض کند.
سومین مورد سمت دور تونل است. مسیر مشتری فقط بسته را روی سیم می‌گذارد؛ دروازه هنوز باید آن را هدایت کند و مسیر برگشت داشته باشد. راهنمای هدایت strongSwan یادآوری است که قواعد هدایت و دیوار آتش روی دروازه بخشی از قابلیت‌اند، نه بخشی از لوله‌کشی که بتوان آن را فرض کرد.
فیلدهایی که یادداشت را اجراپذیر می‌کنند
یک سطر به‌ازای هر جریان، و جریان یعنی مقصد به‌علاوه نام به‌علاوه مالک. این‌ها فیلدهایی هستند که در برخورد با یک حادثه واقعی دوام می‌آورند:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
سطر "کجا زندگی می‌کند" همانی است که مردم از آن می‌گذرند. پیشوندی که سرور هل می‌دهد، مسیری که پروفایل مشتری می‌افزاید و مسیری که در یک پوسته تایپ می‌شود از نظر اینکه چه کسی می‌تواند آن‌ها را تغییر دهد و آیا از اتصال دوباره جان سالم به در می‌برند متفاوت‌اند. بدون آن فیلد، مهندس بعدی نمی‌تواند بگوید کدام یک از سه مورد را می‌بیند.
یک آزمون برای هر قاعده، نه یکی برای هر تونل
هر سطر به دو بررسی بی‌خطر نیاز دارد: یکی که مسیر را می‌آزماید و یکی که نام را. برای مسیر، چیزی بخواهید که باید از تونل عبور کند و مسیر را تأیید کنید نه دسترسی را، برای نمونه tracert -d 10.20.4.11 در Windows یا ip route get 10.20.4.11 در Linux. برای نام، نام خصوصی را پرس‌وجو کنید و ثبت کنید کدام سرور پاسخ داد، با استفاده از resolvectl query files.corp.example یا dig files.corp.example در برابر resolverی که یادداشت نام می‌برد.
یک انتظار منفی هم بیفزایید: وقتی تونل پایین است چه باید رخ دهد. یک برنامه مستثنی روی دستگاه Android یا iOS با مسدودسازی بدون VPN ممکن است اصلاً اتصالی نداشته باشد، و یک مشتری رومیزی می‌تواند همان برنامه را در حین اتصال دوباره تونل فعال نگه دارد. ثبت پاسخ موردنظر "VPN برنامه‌ام را خراب کرد" را به گزاره‌ای قابل بررسی تبدیل می‌کند.
سند را همراه با پیکربندی نگه دارید
یادداشت را کنار پروفایلی که توصیف می‌کند ذخیره کنید و آن را با همان پروفایل نسخه‌بندی کنید. سندی در یک ویکی که هیچ‌کس به‌روزش نمی‌کند شایعه است؛ جدولی در همان مخزنِ مسیرهای هل‌داده‌شده و سیاست resolver را می‌توان در همان تغییر بازبینی کرد.
وقتی چیزی می‌شکند، پیش از افزودن استثنای دیگر، مسیر اعمال‌شده و resolver مؤثر را با سند مقایسه کنید. دو مورد از سه علت رایج — قاعده قدیمی فضای نام و یک فرایند کمکی بیرون از سیاست برنامه — دقیقاً شبیه خرابی VPN به نظر می‌رسند و اگر یادداشت فقط پیشوندها را فهرست کند نامرئی‌اند.
پیش از آنکه یادداشت را تمام‌شده بنامید، تأیید کنید که کتباً به این‌ها پاسخ می‌دهد: کدام پیشوند، برای کدام خانواده نشانی؛ کدام فضای نام خصوصی، با پاسخ کدام resolver؛ کدام نام‌ها عمداً عمومی می‌مانند؛ هر قاعده کجا پیکربندی شده و مالک آن کیست؛ و تنها فرمانی که مسیر را اثبات می‌کند و آن یکی که نام را اثبات می‌کند. اگر هر یک از این‌ها نباشد، حادثه بعدی از صفر تشخیص داده خواهد شد.