مسیریابی ترافیک ماشین مجازی در شبکه فقط میزبان از طریق سرور TUN OpenVPN
تونل و پیشوند فقط میزبان را جدا نگه دارید، مسیر مهمان را هل دهید و سپس به هر ماشین مجازی مسیر بازگشت آگاهانهای از طریق میزبان بدهید.
آداپتورهای فقط میزبان یک شبکه مجازی محلی میسازند و تونلهای TUN مسیریابیشده بستههای IP را بین نشانیها جابهجا میکنند. هیچکدام پلی به دیگری نیست، به همین دلیل یک پیکربندی کارآمد باید بگوید چه کسی ارسال میکند و مسیر بازگشت از آنِ کیست. اگر این دو تخصیص را اشتباه بگیرید، مهمان به تونل با منبعی پاسخ میدهد که کلاینت تونل هرگز آن را نخواسته است. طراحی زیر هر دو پیشوند را جدا نگه میدارد و مسیر بازگشت را صریح میکند.
دو شبکه، دو پیشوند
به استخر تونل و شبکه فقط میزبان پیشوندهای متفاوت بدهید و هرگز یکی را برای دیگری به کار نبرید. در این مثال استخر VPN برابر 10.44.0.0/24 و شبکه فقط میزبان 192.168.99.0/24 است، با میزبان روی 192.168.99.1 و یک مهمان روی 192.168.99.20. اختصاص دادن همان پیشوند به هم دستگاه TUN و هم آداپتور فقط میزبان آنها را به هم متصل نمیکند. دو ادعا روی یک محدوده نشانی میسازد و جدول مسیریابی سپس به نفع ادعایی پاسخ میدهد که تصادفاً حفظ کرده است.
آداپتور فقط میزبان روی میزبان و داخل مهمان وجود دارد، و خودبهخودی راهی برای خروج از ماشین ندارد. اتصالهای پل و NAT در معرض دید متفاوتی هستند و رفتن به حالت پل شرط رسیدن به یک سرویس مهمان نیست.
میزبان از قبل مسیر را دارد
پیش از افزودن هر چیزی ببینید چه چیزی وجود دارد. میزبان یک رابط در شبکه فقط میزبان و یک مسیر برای آن پیشوند دارد که هر دو هنگام بالا آمدن آداپتور ساخته شدهاند.
ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward
خط سوم همان سازوکاری است که میزبان را به یک گام تبدیل میکند. بدون آن، بستهای که از تونل میرسد به شبکهای نشانی میگیرد که میزبان میتواند به آن برسد اما آن را ارسال نخواهد کرد. ارسال لازم است و کافی نیست. سیاست فیلتر همچنان تصمیم میگیرد آیا جریان مشخصی بین رابط تونل و رابط فقط میزبان مجاز است، و آن تصمیم باید نوشته شود نه اینکه در سیاست پیشفرضی بماند که هیچکس نخوانده است.
مسیر را هل دهید، سپس آنچه را به آن میرسد فیلتر کنید
سرور میتواند پیشوند فقط میزبان را به کلاینتهایی بدهد که مسیرهای هلدادهشده را میپذیرند، که همان سازوکار بهکاررفته برای هر زیرشبکه دیگری در پشت تونل است.
push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT
این دو قاعده یک سرویس را در یک جهت و پاسخهایش را مجاز میکنند. مسیری که به کل پیشوند میرسد و فیلتری که یک درگاه را مجاز میکند ترکیبی آگاهانه است؛ مسیر بههمراه پذیرش بیقید و شرط همان راهی است که یک سرویس آزمایشگاهی به سرویس آشکار تبدیل میشود. مسیر هلدادهشده هم مجوز نیست. کلاینت آن را میپذیرد، میزبان آن را ارسال میکند و دیوار آتش مهمان و خود سرویس هنوز نظر میدهند.
مهمان به راه بازگشت نیاز دارد
مهمانی که از 10.44.0.x به آن میرسند باید پاسخهایش را به نشانی فقط میزبانِ میزبان بفرستد، یا میزبان باید منبع را ترجمه کند. گرفتن نشانی از DHCP ویرچوالباکس درباره هیچیک از این دو چیدمان چیزی نمیگوید.
ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15
افزودن آن مسیر درون مهمان منبع اصلی را حفظ میکند که سیاست و گزارشهای هر کلاینت را معنادار نگه میدارد. ترجمه منبع محدود روی میزبان گزینه دیگر است و کار میکند، اما به بهای پنهان کردن اینکه کدام کلاینت متصل شده بود. همپوشانی حالت شکست دیگری است. کلاینت دوردستی که LAN خانهاش از قبل 192.168.99.0/24 را به کار میبرد مسیر هلدادهشده را شبکه خودش میخواند و هیچ تغییری در سمت سرور این ابهام را رفع نمیکند. یک طرف را دوباره شمارهگذاری کنید یا پیشوندی برگزینید که احتمال برخوردش کم است.
دستگاه TUN بستههای IP را حمل میکند، پس افزودن یک دروازه پیشفرض درون مهمان تونل را به قطعه اترنت با آداپتور فقط میزبان تبدیل نمیکند. پلسازی TAP طراحی دیگری با پشتیبانی کلاینت و مالکیت نشانی خودش است و آمیختن این دو توصیف به پیکربندیهایی میرسد که هرگز همگرا نمیشوند.
تأیید کنید، سپس کاری کنید که از راهاندازی مجدد جان سالم ببرد
یک سرویس بیخطر را از یک کلاینت دوردست معمولی بیازمایید، مسیر بازگشت مهمان را بررسی کنید و تأیید کنید سرویسی که مجاز نکردهاید رد میشود نه اینکه کند باشد.
ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20
سپس سرویس VPN و شبکهسازی ماشین مجازی را دوباره راهاندازی کنید و همان سه بررسی را تکرار کنید. مسیری که با دست افزوده شده تا راهاندازی مجدد بعدی دوام میآورد و پیکربندیای که فقط در نشست گرم کار میکند طراحی نیست. دو پیشوند، سیاست ارسال و مسیر مهمان را با هم ثبت کنید. هر کس ماشین مجازی بعدی را بیفزاید به هر سه نیاز دارد و در غیر این صورت آنها را یکییکی با هر اتصال ناموفق دوباره کشف میکند.