دو VPN روی یک ماشین لینوکس: هر یک را جداگانه و بدون قاطی کردن نتایج آزمایش کنید
دو نماد سبز یک مقایسه نیستند. هر تونل را در فضای نام خودش بگذارید، انتظار را اول بنویسید و مسیر را پیش از اعتماد به نتیجه اثبات کنید.
دو نماد سبز اتصال شبیه یک مقایسه به نظر می‌رسند و معمولاً فقط یک تصادف‌اند. اگر درخواست آزمایش می‌توانست از هر یک از دو تونل استفاده کند، نتیجه در بهترین حالت یکی از آن‌ها را توصیف می‌کند و در بدترین حالت هیچ‌کدام را. به هر مشاهده یک زمینهٔ شبکه، یک مقصد موردنظر و انتظاری که پیش از اجرای آزمایش نوشته شده است بدهید. روی یک ماشین لینوکس که خودتان مدیریت می‌کنید، فضاهای نام شبکه‌ای نام‌دار ارزان‌ترین راه برای خریدن این جداسازی هستند.
دو چراغ سبز یک مقایسه نیستند
فضای نام، جدول‌های مسیریابی، رابط‌ها و وضعیت پشتهٔ شبکه را جدا می‌کند، بنابراین درخواستی که در یکی آغاز شده باشد نمی‌تواند بی‌سر‌و‌صدا تونل دیگری را قرض بگیرد. چیزی که جدا نمی‌کند پردازنده، یک اتصال فیزیکی بالادست یا سرویس‌دهندهٔ حل نام است که روی میزبان اجرا می‌شود. همین شکاف آخر جایی است که بیشتر این آزمایش‌ها بدون اینکه کسی متوجه شود شکست می‌خورند. جست‌وجویی که از فضای نام بیرون می‌رود و از حل‌کنندهٔ نام میزبان می‌پرسد، پاسخی برمی‌گرداند که هیچ نسبتی با تونلِ تحت آزمایش ندارد.
این رویه دو فضای نام آزمایشی از پیش آماده و تأییدشده با اتصال بیرونی کارآمد و کارخواه‌های پشتیبانی‌شده را فرض می‌کند. چیزی نمی‌سازد، چیزی ثبت نمی‌کند و هیچ پیکربندی‌ای را جایگزین نمی‌کند. ماشین‌های مجازی جداگانه وقتی کارخواه به یک نشست کامل رومیزی نیاز دارد یا از اجرا در بیرون آن خودداری می‌کند، همچنان انتخاب صادقانه‌اند.
انتظار را پیش از نخستین اجرا تثبیت کنید
برای هر زمینه تصمیم بگیرید که موفقیت چه شکلی است: حل‌کنندهٔ نام، نام سرویس، نشانی مورد انتظار و رفتاری که هنگام افتادن تونل لازم است. آن مقادیر برنامه‌ریزی‌شده را در ستون خودشان نگه دارید، چون سندی که برنامه و مشاهده را قاطی کند داستانی با مُهر زمان است. سیاههٔ بازبینی زیر همان شکلی است که سند لازم دارد و هر ردیف باید پیش از نخستین اتصال قابل پر شدن باشد.
| Tunnel | Owner | Client interface inside the namespace | Proof command | Required on disconnect |
|---|---|---|---|---|
| vpn-a | the identity that owns profile A, recorded by name | its own tun device, never the host's | ip -n vpn-a -4 route get 10.55.10.20 | traffic stops; no host-side fallback |
| vpn-b | a separate owner, even when both run on one box | its own tun device in its own namespace | ip -n vpn-b -4 route get 10.55.20.20 | verified separately, never inferred from A |
سیم‌کشی حل‌کنندهٔ نام در آن سند ردیف خودش را می‌خواهد، چون این همان میدانی است که بیش از همه احتمال دروغ گفتن دارد. پرونده‌های وابسته به فضای نام، مانند /etc/netns/vpn-a/resolv.conf در مسیرهای معمول خود ظاهر می‌شوند وقتی فرمانی درون فضای نام اجرا می‌شود، همان‌گونه که مرجع iproute2 دربارهٔ فضاهای نام توضیح می‌دهد، اما پیکربندی تعویض سرویس نام و هر حل‌کنندهٔ محلی که اجرا کند باز هم می‌توانند جست‌وجو را به میزبان بازکشند.
هر بار یک تونل، دیگری قطع
A را از طریق مالک موجودش وصل کنید در حالی که B پایین می‌ماند، سپس سیاست، مسیرها و مسیر انتخاب‌شده را از زمینهٔ مدیریت بررسی کنید. سه فرمان زیر وضعیت را می‌خوانند؛ تنها فرمان آخر با یک سرویس نام تماس می‌گیرد و هیچ‌کدام درخواست برنامه‌ای نمی‌فرستند.
sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internalجست‌وجوی مسیر به پرسشی فرضی دربارهٔ یک مقصد پاسخ می‌دهد، پس نمی‌تواند نشان دهد که سرویس ترافیک را می‌پذیرد. این دو نوع شاهد را در ستون‌های جدا نگه دارید، چون مسیر سالم در کنار اتصال ردشده نتیجه‌ای واقعی و رایج است. سپس یک درخواست بی‌ضرر و مجاز با برنامهٔ واقعی بفرستید، که در زمینهٔ A به‌عنوان کاربر عادی بدون امتیازش اجرا می‌شود و اعتبارسنجی گواهی و احراز هویت برنامه دست‌نخورده می‌ماند، و نتیجه را همراه با نشانی مبدأیی که سرویس دیده ثبت کنید. A را از طریق مالکش قطع کنید و کل خط پایه را برای B تکرار کنید و هر تغییر پیکربندی را که می‌دهید یادداشت کنید، وگرنه دو خط پایه دیگر قابل مقایسه نیستند.
هر دو بالا، سپس هر بار یکی پایین
وضعیت پایدار بخش آسان است. با هر دو تونل وصل، جست‌وجو و درخواست برنامهٔ هر زمینه را تکرار کنید، سپس یک تونل را بشکنید و دیگری را بررسی کنید. وقتی خود ترتیب اتصال پرسش باشد، به ترتیب معکوس دوباره وصل شوید.
sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20ثبت بسته‌ها بحث‌هایی را حل می‌کند که نتیجهٔ یک برنامه نمی‌تواند: نشان می‌دهد درخواست از رابطی که انتظار داشتید بیرون رفته یا از چیزی کاملاً دیگر. برای هر گذار کنش مالک، مُهر زمان، نتیجهٔ مسیر، نتیجهٔ نام و پیامد برنامه را ثبت کنید. سپس شرط بسته‌شدن ایمن را درون فضای نام آسیب‌دیده بررسی کنید، چون جداسازی یک کلید قطع نیست. فضای نام دو تونل را از هم دور نگه می‌دارد؛ جلوی هیچ‌کدام را نمی‌گیرد که وقتی نمایه‌اش می‌گوید ترافیک باید بایستد، ترافیک حمل کند.
این سند چه چیزی را می‌تواند ادعا کند و چه چیزی را نه
یک قبولی آن مشاهدات را برای این چیدمان، روی این میزبان، در آن زمان اثبات می‌کند. هیچ چیزی دربارهٔ دو کارخواه که یک جدول مسیریابی رومیزی را شریک‌اند نمی‌گوید و هیچ چیزی دربارهٔ گذردهی در حالی که هر دو تونل بار می‌برند. این‌ها پرسش‌های جدا با آزمایش‌های جدا هستند و مقایسه تنها به اندازهٔ زمینه‌ای خوب است که به هر ردیف پیوست شده.
شکست‌ها را در سند کنار موفقیت‌ها نگه دارید، با این برچسب که آن زمان کدام تونل بالا بود. صفحهٔ تمیزی که وضعیت را در لحظهٔ اندازه‌گیری پنهان می‌کند بدتر از صفحهٔ زشتی است که آن را نشان می‌دهد. چیزی که سند را بعداً قابل استفادهٔ دوباره می‌کند زمینه است، نه امتیاز.
دو تونل روی یک ماشین را می‌توان صادقانه مقایسه کرد، اما فقط در همان تعداد زمینه‌ای که واقعاً کنترل کردید. هر چیزی فراتر از آن آرزویی است با یک نماد سبز در کنارش.