آزمایشگاه VPN در VirtualBox: ماشین مجازی دروازه در برابر شبکه فقط میزبان
برای آزمایشگاه VPN در VirtualBox میان ماشین مجازی دروازه مسیریابی‌شده و بخش فقط میزبان یکی را برگزینید، سپس کاری کنید که مهمان هنگام افتادن تونل بسته شکست بخورد.
باید تصمیم بگیرید که آزمایشگاه VPN شما چقدر ماشین‌آلات می‌ارزد. یک ماشین مجازی دروازه مسیریابی‌شده میان دو بخش VirtualBox، ترجمه نشانی، مسیر بازگشت و جایگاه دیوار آتشی را که یک کارخواه واقعی پشت آن می‌نشیند بازتولید می‌کند. یک بخش تنها با میزبان به شما یک دروازه کنترل‌شده می‌دهد و هیچ چیز دیگر. نسخه دروازه سه مهمان و یک جدول مسیریابی که خود نگه می‌دارید هزینه دارد؛ نسخه تنها با میزبان یک مهمان و یک سیاست. سه پرسش آن‌ها را جدا می‌کند و سومی تعیین می‌کند که آزمون شما اصلاً می‌تواند قبول شود یا نه.
پیش از شبیه‌سازی هر چیز، به سه پرسش پاسخ دهید
با آنچه سرور VPN باید ببیند آغاز کنید. اگر سرور باید نشانی مبدأیی ببیند که نشانی مهمان آزمون نیست، چیزی باید میان آن دو ترجمه کند و آن چیز باید مسیریابی باشد که شما کنترل می‌کنید. شبکه‌سازی تنها با میزبان به میزبان یک کارت شبکه در بخش مهمان می‌دهد، نه یک مترجم. وقتی مهمان سپس باید به چیزی بیرون دست یابد، یک کارت NAT وصل می‌کنید و موتور NAT خود VirtualBox مبدأ را بدون پرسیدن از شما بازنویسی می‌کند.
سپس بپرسید آیا مهمان می‌تواند به چیزی جز از راه تونل دست یابد. آن پاسخ داخلی یا تنها با میزبان را برمی‌گزیند و همان پرسشی است که بیشتر نوشته‌های آزمایشگاهی از آن می‌گذرند. در پایان بپرسید وقتی تونل می‌افتد چه باید رخ دهد، زیرا آن سیاست را تعیین می‌کند نه توپولوژی، و آزمایشگاهی که فقط مسیر خوش‌بینانه را اثبات کند تقریباً هیچ چیز را نیازموده است.
| What the test requires | Routed gateway VM | Host-only guest |
|---|---|---|
| Server sees a translated source address | Yes, from your own MASQUERADE rule | No, VirtualBox NAT does it instead |
| The guest has exactly one egress | Yes, while the second adapter faces the tunnel | Only until a NAT adapter is attached |
| Policy is testable during a tunnel failure | Rules live in one place | Rules live on each guest |
سه نقش را با شبکه‌های داخلی به هم وصل کنید
سه مهمان و دو بخش نام‌دار به کار ببرید، با دروازه به‌عنوان تنها ماشینی که در هر دو کارت شبکه دارد:
VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LANبرای شبکه داخلی گام ساخت جداگانه‌ای وجود ندارد. رشته در --intnet1 همان بخش است: دو ماشین تنها وقتی آن را شریک می‌شوند که نام دقیقاً یکی باشد و هیچ چیز روی میزبان به آن وصل نیست. همین ویژگی آخر دلیل تکرار پاکیزه آزمایشگاه است، چون مسیرهای میزبان، کارخواه VPN خودش و دیوار آتش آن نمی‌توانند تصادفی به مهمان‌ها برسند. بخش داخلی همچنین سرور DHCP ندارد مگر اینکه یکی بیفزایید، پس نشانی‌های ثابت کوتاه‌ترین راه‌اند.
به کارخواه فقط نشانی WAN خودش را بدهید، با دروازه پیش‌فرضی که به نشانی WAN دروازه اشاره کند. سرور نشانی LAN می‌گیرد و نشانی LAN دروازه را دروازه پیش‌فرض خود می‌کند. مهمانی که دو نشانی در یک بخش نگه می‌دارد یا مسیر گم‌شده‌ای به بخش دیگر دارد، راهی دور مسیریاب دارد و آزمون‌های پایین به شما دروغ خواهند گفت.
کنار نام ماشین‌های مجازی یک پرونده متنی با چهار نشانی و دو نام بخش نگه می‌دارم و آن را در هر پوسته می‌چسبانم. هفته‌ها بعد، وقتی تغییری در نمایه چیزی را می‌شکند، همان پرونده تفاوت میان اشکال‌زدایی نمایه و اشکال‌زدایی حافظه خودم است.
برای بخشی که نباید نشت کند، داخلی یا تنها با میزبان را برگزینید
حالت تنها با میزبان یک کارت شبکه مجازی روی خود میزبان می‌سازد، معمولاً vboxnet0، و به میزبان نشانی‌ای در بخش مهمان می‌دهد. این برای مدیریت راحت و برای آزمون جداسازی مرگبار است، چون میزبان اکنون می‌تواند مستقیم به مهمان برسد و هر خدمتی در سمت میزبان راهی ممکن می‌شود. حالت داخلی هیچ کارت میزبانی ندارد. این دو حالت در تابلوی تنظیمات شبکه به‌آسانی اشتباه می‌شوند، پس تفاوت مستند را بررسی کنید نه برچسب را (صفحه جزئیات شبکه VirtualBox را ببینید).
برای مهمانی که باید از تونل استفاده کند، داخلی پیش‌فرض ایمن‌تر است، با دروازه به‌عنوان تنها راه خروج. اگر تنها با میزبان را نگه می‌دارید، کارت میزبان را یک مسیر مدیریت بدانید و آن را بلند بگویید: میزبان می‌تواند به مهمان برسد و مهمان نباید بتواند از میزبان به‌عنوان خروجی استفاده کند.
VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0جداسازی‌ای که می‌توانید اثبات کنید همان جداسازی‌ای است که پیکربندی کرده‌اید. مهمانی با یک کارت داخلی، مسیر پیش‌فرض روی دروازه و بدون کارت NAT هیچ راهی ندارد که دروازه را دور بزند. مهمانی با کارت تنها با میزبان و کارت NAT دو راه دارد و تنها یکی از آن‌ها همانی است که می‌خواستید بیازمایید.
روی دروازه مسیریابی و ترجمه کنید، سپس کاری کنید که هنگام شکست بسته شود
VirtualBox میان بخش‌ها فرستادن نمی‌کند؛ مهمان این کار را می‌کند. با ماشین مجازی سرور VPN پشت دروازه، فرستادن را فعال کنید و ترافیک کارخواه را هنگام خروج به سوی سرور ترجمه کنید:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADEبا این قاعده سرور نشانی LAN دروازه را به جای نشانی کارخواه می‌بیند، و کارخواه واقعی پشت NAT اپراتور از دید سر شبکه همین‌گونه دیده می‌شود. مقدار sysctl را در /etc/sysctl.d/ و قاعده را در هر سرویس دیوار آتشی که توزیع به کار می‌برد ذخیره کنید، وگرنه یک راه‌اندازی دوباره آزمایشگاه را بی‌صدا به وضعیت مسیریابی‌شده اما ترجمه‌نشده بازمی‌گرداند.
فرستادن مجوز نیست. زیر سیاست پیش‌فرض FORWARD با مقدار ACCEPT، مهمانی که مسیر پیش‌فرضش به دروازه اشاره می‌کند از هر رابطی که جدول مسیریابی برگزیند بیرون می‌رود، با تونل یا بی‌تونل. اگر دروازه کارت NAT هم برای نصب بسته‌ها داشته باشد، آن کارت همان لحظه‌ای که تونل می‌افتد یک خروجی کارآمد رمزنگاری‌نشده است و آزمون فقط-VPN شما هرگز آزمون فقط-VPN نبوده است.
وقتی سرور به‌جای آن دور است و خود دروازه تونل را پایان می‌دهد، همان تصمیم به رابط تونل اشاره می‌کند، نه به کارت شبکه‌ای که به اینترنت می‌رسد:
iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTحمل بیرونی خود تونل و مسیر مدیریت خارج از باند را از ترافیک فرستاده‌شده جدا نگه دارید. اگر تنها راه تعمیر دروازه از راه تونلی است که اشکال‌زدایی می‌کنید، آزمایشگاه به تمرینی در قفل‌شدن تبدیل می‌شود. یک کنسول سریال، یک کارت مدیریت تنها با میزبان یا یک عکس لحظه‌ای از وضعیت سالم شناخته‌شده ارزان‌تر از بازیابی دستی یک مسیریاب خراب است.
مسیر را از مهمان بررسی کنید، نه از میزبان
به سمت بیرون کار کنید. تأیید کنید که کارخواه به نشانی WAN دروازه می‌رسد، سپس از راه دروازه به سرور، سپس اینکه اتصالی به درگاه VPN بیرون می‌رود و بازمی‌گردد. ثبت روی هر دو رابط دروازه نشان می‌دهد پاسخ می‌رسد و در مسیر بازگشت انداخته می‌شود یا نه، چیزی که ثبت تنها روی کارخواه نمی‌تواند تشخیص دهد:
tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194سپس خروجی را اثبات کنید. از مهمان از یک سرویس بازتاب نشانی بپرسید چه مبدأیی می‌بیند و آن را با نشانی خروج خود دروازه بسنجید؛ اگر پاسخ با نشانی میزبان یکی باشد، راهی دور تونل وجود دارد. بررسی کنید مهمان در واقع از کدام حل‌کننده استفاده می‌کند و IPv6 را جداگانه بررسی کنید، چون بخشی که IPv6 در آن فعال است در حالی که تونل تنها IPv4 را حمل می‌کند، بر اساس طراحی نشت می‌کند نه از روی تصادف.
در پایان، آن را عمداً بشکنید. تونل را متوقف کنید یا درگاه بیرونی‌اش را مسدود کنید و از مهمان اتصال تازه‌ای باز کنید. باید شکست بخورد و دلیل باید چیزی باشد که بتوانید نام ببرید: مسیری نیست، قاعده رد وجود دارد یا حل‌کننده مرده است. تونل را دوباره راه بیندازید و تأیید کنید مهمان بدون بازسازی شبکه بهبود می‌یابد. اگر یک VPN مشبک مانند Hamachi یا ZeroTier آزمایشگاه را شریک می‌شود، یادتان باشد که کارت پل‌شده نام کارت را دنبال می‌کند نه مشبک را، پس پل باید پس از نصب کارت مجازی خود توسط کارخواه دوباره نشانه‌گذاری شود.
VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>هم‌رسانی تونل مهمان با میزبان همان مشکل را بازمی‌تاباند. نشانه‌گذاری مسیر پیش‌فرض میزبان به مهمان کار می‌کند و یک پیشکار درون مهمان هم؛ NAT از راه میزبان تونل مهمان را برای ترافیکی که میزبان آغاز کرده است حمل نمی‌کند. نام بخش‌ها و قاعده‌های دیوار آتش را در یک جا ذخیره کنید، از وضعیت کارآمد عکس لحظه‌ای بگیرید و نشانی مبدأیی را که سرور دیده ثبت کنید. آن‌گاه تغییر نمایه بعدی یک اجرای اسکریپت هزینه دارد نه یک آزمایشگاه بازساخته.