بررسی کنید که تونل تقسیم‌شده کار می‌کند: یک نتیجه IP آزمون نیست
بنویسید کدام جریان‌ها باید از تونل استفاده کنند و کدام باید مستقیم بمانند، سپس هر دو طرف، تقسیم DNS و حالت خرابی را بیازمایید.
یک صفحه مرورگر که نشانی IP را نشان می‌دهد تقریباً هیچ چیز درباره تونل تقسیم‌شده اثبات نمی‌کند. نشانی قابل مشاهده می‌تواند به دلیل نادرست درست باشد، و جریان حذف‌شده هرگز با آن آزموده نمی‌شود. پیش از آزمون نتیجه مورد انتظار را بنویسید: کدام برنامه یا مقصد باید از تونل استفاده کند، کدام باید مستقیم بماند، و چه چیزی باید متوقف شود وقتی تونل از کار می‌افتد. بدون آن طرح، هر عدد باورپذیر شبیه موفقیت به نظر می‌رسد.
افسانه: جستجوی نشانی پوشش را اثبات می‌کند
بررسی IP به یک پرسش پاسخ می‌دهد: جهان بیرون در یک لحظه از یک برنامه چه می‌بیند. چیزی درباره پیشوند داخلی، نمایه دوم مرورگر یا نامی که باید به‌صورت خصوصی حل شود نمی‌گوید. درباره خرابی هم چیزی نمی‌گوید، و آن نیمی از طراحی تونل تقسیم‌شده است که در محیط عملیاتی می‌شکند.
صفحه نشانی هم نمی‌تواند مسیر، حل‌کننده یا سیاست خرابی را نشان دهد. آن را یک مشاهده بدانید، نه یک حکم.
یک جریان شامل و یک جریان حذف‌شده را بیازمایید
یک درخواست بی‌ضرر از برنامه‌ای که باید شامل باشد، یا به پیشوندی که انتظار دارید از تونل عبور کند بفرستید و منبع، مقصد، خانواده نشانی‌ها و مسیر مشاهده‌شده را ثبت کنید. همین کار را برای جریانی که باید مستقیم بماند انجام دهید. طرف حذف‌شده همان طرفی است که مردم از آن می‌گذرند، و تنها شاهد آن است که تقسیم عمدی است نه تصادفی. یک فرایند کمکی می‌تواند هویت سیاست جداگانه داشته باشد، پس در فرایندی بیازمایید که سوکت را در اختیار دارد.
flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, directبه همین دلیل آزمون در برنامه نادرست می‌تواند عکس آنچه طراحی می‌خواهد را نشان دهد. چهار میدان را برای هر دو طرف بنویسید پیش از آنکه نتیجه‌گیری کنید.
DNS و حالت خرابی را اضافه کنید
از حل‌کننده سیستم و حل‌کننده‌ای که برنامه استفاده می‌کند بپرسید، سپس آن پاسخ‌ها را با نشانی خروجی که سایت گزارش می‌کند مقایسه کنید. این دو لایه می‌توانند عمداً ناهمخوان باشند، و یک جستجوی مرورگر سیاست سیستم‌عامل را نمی‌آزماید. پوسته مقایسه را تکرارپذیر می‌کند: تونل را عمداً قطع کنید، سپس درخواستی بسازید که مرورگر آن را در حافظه نهان ندارد؛ صفحه‌ای که از حافظه نهان سرو می‌شود چیزی درباره جهت مسیر جانشین نمی‌گوید. آنچه واقعاً رخ داد را ثبت کنید، نه آنچه طراحی پیش‌بینی کرد.
curl -s https://ifconfig.me
nslookup intranet.exampleتونل تقسیم‌شده‌ای که بسته شکست می‌خورد و آنکه باز شکست می‌خورد تا زمانی که تونل را عمداً قطع نکنید یکسان به نظر می‌رسند. رفتار مشاهده‌شده را ثبت کنید، نه رفتاری که انتظار داشتید.
پس از تغییر وضعیت تکرار کنید
همان مشاهده‌ها را پس از اتصال دوباره، تغییر شبکه و به‌روزرسانی مرتبط برنامه تکرار کنید. یک استثنای ذخیره‌شده می‌تواند همچنان به مسیر یا هویت برنامه‌ای اشاره کند که دیگر وجود ندارد، و طراحی بی‌صدا از مطابقت با مستنداتش باز می‌ماند. آن سه رویداد جاهایی هستند که تونل‌های تقسیم‌شده لغزش می‌کنند، و آزمون دوباره هر یک ارزان است. آزمونی که فقط یک بار هنگام استقرار اجرا می‌شود پیکربندی‌ای را توصیف می‌کند که دیگر وجود ندارد.
اگر نتیجه‌ای متفاوت بود، پیش از تغییر چند تنظیم هم‌زمان، صاحب قاعده و مرحله پردازش را پیدا کنید. تغییر پنج چیز و مشاهده یک نتیجه تشخیص نیست، پیکربندی تازه است.
نتیجه باید چه چیزی را اثبات کند
مشاهده‌ها را به سیاست و نسخه مشتری که واقعاً آزمودید گره بزنید. هدف نشان دادن این است که این استقرار با پوششی که ادعا می‌کند مطابقت دارد، نه اینکه هر برنامه آینده خصوصی خواهد بود. این ادعای محدودتری است و همان چیزی است که واقعاً می‌توانید با شواهد پشتیبانی کنید. ادعا، نسخه و نتایج چهار میدان را در سابقه تغییر بنویسید.
آنگاه بازبین بعدی می‌تواند بگوید طراحی تغییر کرده یا آزمون. تونل تقسیم‌شده هنگامی تأیید می‌شود که هر دو طرف، تقسیم حل‌کننده و رفتار در زمان خرابی با آنچه در آغاز نوشتید مطابقت داشته باشند. یک نتیجه IP هیچ‌یک از آن‌ها را تأیید نمی‌کند.