آزمایشگاه خانگی و تونل تقسیم‌شده: آنچه لازم دارید را مسیردهی کنید، نه همه چیز
تونل کامل یک عادت از آموزش‌ها است، نه الزام آزمایشگاه. زیرشبکه‌ها، نام‌ها و مسیرهای مدیریتی که واقعاً لازم دارید را فهرست کنید، سپس فقط همان‌ها را مسیردهی کنید.
این توصیه که یک آزمایشگاه خانگی به تونل کامل نیاز دارد معمولاً از آموزشی می‌آید که خودش تونل کامل داشت، نه از یک الزام. تونل تقسیم‌شده نسخهٔ سازش‌شدهٔ یک VPN درست نیست؛ نسخه‌ای است که می‌توانید جدول مسیرهایش را توضیح دهید. آزمایشگاهی با پنج سرویس و یک رابط مدیریت به این نیاز ندارد که هر بسته‌ای که خانه را ترک می‌کند از تونل عبور کند. آنچه لازم دارد یک فهرست و یک مسیر برای هر قلم آن فهرست است.
افسانه: تونل تقسیم‌شده یک سازش است
افسانه می‌ماند چون تونل کامل یک بار آسان‌تر تنظیم می‌شود و بعداً سخت‌تر اشکال‌زدایی می‌شود. آن معامله برای لپ‌تاپی روی Wi-Fi عمومی معقول و برای قفسه‌ای در زیرزمین نادرست است.
همچنین فرض دومی را پنهان می‌کند: اینکه آدرس‌دهی آزمایشگاه هیچ وجه اشتراکی با شبکه‌ای که از آن وصل می‌شوید ندارد.
پیش از مسیرها، منابع را فهرست کنید
هر زیرشبکهٔ آزمایشگاه، سرویسی که آنجا زندگی می‌کند، نامی که با آن حلش می‌کنید و کسی که اجازهٔ دسترسی به آن را دارد بنویسید؛ یادداشت‌های هدایت برای دروازهٔ شما مسیر بازگشتی را که بر اساسش برنامه‌ریزی می‌کنید توصیف می‌کنند. بازه‌های کانتینر و بازه‌های LAN را که کلاینت دور ممکن است از قبل استفاده کند اضافه کنید، چون همپوشانی همان شکستی است که این فهرست از آن جلوگیری می‌کند. مسیری که هر نشانی خصوصی را بپوشاند دیر یا زود با یک شبکهٔ خانگی برخورد می‌کند. این فهرست همان طرح آزمون هم هست، از این رو ارزش دارد آن را پیش از پیکربندی انجام دهید نه پس از آن.
به هر منبع یک مسیر بدهید: از تونل، مستقیم، یا مسدود. منبعی که مسیر نگرفته همان چیزی است که بعداً پرسش پشتیبانی گیج‌کننده را می‌سازد.
پنج ردیف و یک ستون تصمیم بر جدول مسیری که هیچ‌کس نمی‌تواند بخواند پیروز می‌شود.
دروازه به مسیر بازگشت نیاز دارد
هدایت روی دروازه فقط نیمی از کار است. آزمایشگاه به مسیری بازگشتی به استخر کلاینت‌ها نیاز دارد، یا به ترتیبی پشتیبانی‌شده از ترجمه که بازگشت را ممکن کند. اگر پاسخ‌ها نتوانند کلاینت را پیدا کنند، تونل متصل به نظر می‌رسد و هر درخواست به پایان زمان می‌رسد؛ این نشانهٔ مسیریابی است نه شکست VPN. مسیر بازگشت را به عنوان بخشی از طراحی بررسی کنید، نه به عنوان گامی از عیب‌یابی.
استخری از کلاینت‌ها که با آدرس‌دهی خود آزمایشگاه همپوشانی دارد نیمهٔ دیگر این مشکل است، و دقیقاً به همان شکل شکست می‌خورد.
وقتی دو بازه برخورد می‌کنند طرح را درست کنید، نه نشانه‌ها را.
نقش‌های مدیریت و اینترنت جدا از هم‌اند
تصمیم بگیرید که آیا فقط ترافیک آزمایشگاه از تونل استفاده می‌کند یا آن هم به خروجی اینترنت تبدیل می‌شود. فقط به این دلیل که آموزشی از یک مسیر پیش‌فرض استفاده کرده آن را اضافه نکنید، چون این تصمیم تغییر می‌دهد که هر پرس‌وجوی DNS و هر بررسی به‌روزرسانی کجا برود. مسیری بیرونی به خود نقطهٔ پایانی VPN نگه دارید، وگرنه تونل تلاش می‌کند اتصال بیرونی خودش را حمل کند. دسترسی مدیریت را باریک و از طریق روش بازیابی تأییدشده در دسترس نگه دارید.
می‌توان DNS خصوصی را برای نام‌های آزمایشگاه انتخاب کرد بدون آنکه فرض کنیم هر پرس‌وجوی عمومی به همان حل‌کننده نیاز دارد. این تصمیم حل‌کننده است، نه تصمیم مسیر.
جدا نگه داشتن آن‌ها همان چیزی است که حالت‌های شکست را بعداً قابل تشخیص می‌کند.
از بیرون آزمایش کنید، نه از LAN
به جای آزمون از همان LAN از یک اتصال بیرونی مجاز استفاده کنید، چون آزمون از همان LAN می‌تواند مسیر بازگشت گم‌شده را کاملاً پنهان کند. یک نشانی آزمایشگاه، نام میزبان خصوصی آن، یک مقصد مستقیم مورد نظر و رفتار شکست لازم را بررسی کنید. مورد شکست به اندازهٔ مورد موفقیت مهم است: منبعی که باید دسترسی‌ناپذیر باشد باید واقعاً دسترسی‌ناپذیر باشد. همهٔ چهار نتیجه را ثبت کنید پیش از آنکه طراحی را تمام‌شده بنامید.
سپس پیکربندی مسیر و DNS را کنار فهرست ذخیره کنید، با نام یک مالک. وقتی آزمایشگاه زیرشبکهٔ دیگری می‌گیرد، هر دو را به‌روز کنید و دوباره آزمایش کنید.
مسیر توضیح‌داده‌نشده‌ای که با شبکهٔ خانگی موجود همپوشانی دارد نتیجهٔ پیش‌فرض نادیده گرفتن آن گام است.
طراحی تمام‌شده کوچک، مستند و خسته‌کننده است، و این دقیقاً همان چیزی است که یک آزمایشگاه از شبکه‌اش می‌خواهد. نسخهٔ جالب آن نسخه‌ای است که وقتی از خانه دور هستید می‌شکند.