VirtualBox VPN laboratoriyası: şlüz VM-i, yoxsa yalnız host şəbəkəsi

VPN laboratoriyanızın nə qədər mexanizmə layiq olduğuna qərar verməlisiniz. İki VirtualBox seqmenti arasında marşrutlaşdırılmış şlüz VM-i ünvan çevrilməsini, geri dönüş yolunu və real müştərinin arxasında dayandığı firewall mövqeyini təkrar yaradır. Tək bir yalnız host seqmenti sizə bir nəzarətli qapı və başqa heç nə vermir. Şlüz versiyası üç qonaq və saxladığınız bir marşrut cədvəli bahasına başa gəlir; yalnız host versiyası bir qonaq və bir siyasət bahasına. Onları üç sual ayırır və üçüncüsü testinizin ümumiyyətlə keçə biləcəyini həll edir.

Heç nəyi klonlamazdan əvvəl üç suala cavab verin

VPN serverinin nəyi müşahidə etməli olduğu ilə başlayın. Əgər server test qonağının olmayan mənbə ünvanını görməlidirsə, onların arasında nəyinsə çevrilmə etməsi lazımdır və o nəyinsə sizin nəzarət etdiyiniz marşrutlaşdırıcı olması vacibdir. Yalnız host şəbəkə hosta qonağın seqmentində adapter verir, tərcüməçi yox. Qonaq sonra kənara çıxmalı olduqda NAT adapteri qoşursunuz və VirtualBox-un öz NAT mühərriki mənbəni sizdən soruşmadan yenidən yazır.

Sonra qonağın tuneldən başqa hər hansı yerə çıxa biləcəyini soruşun. Bu cavab daxili və ya yalnız host seçimini edir və bu, əksər laboratoriya yazılarının atladığı sualdır. Nəhayət, tunel düşəndə nə baş verməli olduğunu soruşun, çünki bu, topologiyadan çox siyasəti həll edir və yalnız xoşbəxt yolu sübut edən laboratoriya demək olar ki, heç nə sınamamışdır.

Üç rolu daxili şəbəkələrlə birləşdirin

Üç qonaq və iki adlandırılmış seqment istifadə edin, şlüz hər ikisində adapter saxlayan yeganə maşın olsun:

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

Daxili şəbəkə üçün ayrıca yaratma addımı yoxdur. --intnet1 içindəki sətir seqmentdir: iki maşın onu yalnız ad tam uyğun gəldikdə paylaşır və hostda heç nə ona qoşulmur. Bu son xassə laboratoriyanın təmiz təkrarlandığının səbəbidir, çünki hostun marşrutları, öz VPN müştərisi və firewall-u qonaqlara təsadüfən çata bilməz. Daxili seqmentdə siz əlavə etməsəniz DHCP serveri də yoxdur, ona görə statik ünvanlar ən qısa yoldur.

Müştəriyə yalnız WAN ünvanını verin, standart şlüz şlüzün WAN ünvanına baxsın. Server LAN ünvanı alır və şlüzün LAN ünvanını standart şlüz kimi istifadə edir. Bir seqmentdə iki ünvan saxlayan və ya digər seqmentə səhv marşrutu olan qonağın marşrutlaşdırıcının ətrafından keçən yolu var və aşağıdakı testlər sizə yalan deyəcək.

VM adlarının yanında dörd ünvanı və iki seqment adını saxlayan mətn faylı saxlayıram və onu hər shell-ə yapışdırıram. Həftələr sonra profil dəyişikliyi nəyisə pozanda həmin fayl profili sazlamaqla öz yaddaşımı sazlamaq arasındakı fərq olur.

Sızmayan seqment üçün daxili və ya yalnız host seçin

Yalnız host rejimi hostun özündə virtual adapter yaradır, adətən vboxnet0, və hosta qonağın seqmentində ünvan verir. Bu, idarəetmə üçün rahat, izolyasiya testi üçün isə ölümcüldür, çünki host artıq qonağa birbaşa çata bilir və host tərəfindəki hər xidmət mümkün yol olur. Daxili rejimdə heç bir host adapteri yoxdur. İki rejimi şəbəkə parametrləri panelində qarışdırmaq asandır, ona görə etiketə deyil, sənədləşdirilmiş fərqə baxın (VirtualBox şəbəkə təfərrüatları səhifəsinə baxın).

Tuneldən istifadə etməli olan qonaq üçün daxili daha təhlükəsiz standartdır, şlüz yeganə çıxışdır. Yalnız hostu saxlasanız, host adapterini idarəetmə yolu kimi qəbul edin və bunu açıq deyin: host qonağa çata bilər, qonaq isə hostdan çıxış kimi istifadə edə bilməməlidir.

VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0

Sübut edə bildiyiniz izolyasiya konfiqurasiya etdiyiniz izolyasiyadır. Bir daxili adapteri, şlüzdə standart marşrutu və NAT adapteri olmayan qonağın şlüzü atlayan yolu yoxdur. Yalnız host adapteri və NAT adapteri olan qonağın iki yolu var və onlardan yalnız biri sınamaq istədiyiniz yoldur.

Şlüzdə marşrutlaşdırın və çevirin, sonra onu qapalı şəkildə uğursuz edin

VirtualBox seqmentlər arasında yönləndirmir; bunu qonaq edir. VPN server VM-i şlüzün arxasındadırsa, yönləndirməni aktivləşdirin və müştərinin trafikini serverə doğru çıxarkən çevirin:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Bu qayda ilə server müştərinin yerinə şlüzün LAN ünvanını görür və real müştərinin operator NAT-ı arxasından baş ucuna görünüşü elə budur. sysctl dəyərini /etc/sysctl.d/ içində, qaydayı isə distributiv hansı firewall xidmətindən istifadə edirsə onda saxlayın, əks halda yenidən başlatma laboratoriyanı səssizcə marşrutlaşdırılmış, lakin çevrilməmiş vəziyyətə qaytarır.

Yönləndirmə icazə deyil. ACCEPT-in standart FORWARD siyasəti altında standart marşrutu şlüzə baxan qonaq marşrut cədvəlinin seçdiyi interfeysdən, tuneldən ya yox, çıxır. Əgər şlüzün paket quraşdırmaları üçün NAT adapteri də varsa, həmin adapter tunel düşən anda işlək şifrələnməmiş çıxışdır və yalnız VPN testiniz heç vaxt yalnız VPN testi olmamışdır.

Server əvəzində uzaqdadırsa və tuneli şlüz özü sonlandırırsa, eyni qərar internetə çatan NIC-ə deyil, tunel interfeysinə işarə edir:

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

Tunelin öz xarici nəqliyyatını və bantdan kənar idarəetmə marşrutunu yönləndirilən trafikdən ayrı saxlayın. Şlüzü təmir etməyin yeganə yolu sazladığınız tuneldən keçirsə, laboratoriya kilidlənmə məşqinə çevrilir. Seriyalı konsol, yalnız host idarəetmə adapteri və ya bilinən yaxşı vəziyyətin snapshot-u pozulmuş marşrutlaşdırıcını əl ilə bərpa etməkdən ucuzdur.

Yolu hostdan deyil, qonaqdan yoxlayın

Bayıra doğru işləyin. Müştərinin şlüzün WAN ünvanına, sonra şlüz vasitəsilə serverə, sonra VPN portuna bağlantının çıxıb qayıtdığını təsdiqləyin. Hər iki şlüz interfeysində tutma cavabın gəlib geri dönüş yolunda atıldığını göstərir, bunu yalnız müştəridə tutma ayırd edə bilməz:

tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194

Sonra çıxışı sübut edin. Qonaqdan ünvan əks etdirmə xidmətindən hansı mənbəni gördüyünü soruşun və bunu şlüzün öz çıxış ünvanı ilə müqayisə edin; cavab hostun ünvanı ilə uyğun gəlirsə, tunelin ətrafında yol var. Qonağın həqiqətən hansı resolver-dən istifadə etdiyini yoxlayın və IPv6-nı ayrıca yoxlayın, çünki IPv6-nın aktiv olduğu, tunelin isə yalnız IPv4 daşıdığı seqment təsadüfən deyil, dizayn üzrə sızır.

Nəhayət, onu qəsdən pozun. Tuneli dayandırın və ya xarici portunu bloklayın və qonaqdan yeni bağlantı açın. Uğursuz olmalıdır və səbəb adlandıra bildiyiniz biri olmalıdır: marşrut yoxdur, rədd qaydası var və ya resolver ölüdür. Tuneli yenidən başladın və qonağın şəbəkəni yenidən qurmadan bərpa olduğunu təsdiqləyin. Hamachi və ya ZeroTier kimi mesh VPN laboratoriyanı paylaşırsa, körpülənmiş adapterin mesh-ə deyil, adapter adına tabe olduğunu unutmayın, ona görə müştəri öz virtual adapterini quraşdırdıqdan sonra körpü yenidən göstərilməlidir.

VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>

Qonağın tunelini hostla paylaşmaq problemi əks etdirir. Hostun standart marşrutunu qonağa yönəltmək işləyir, qonağın içində proxy də işləyir; host vasitəsilə NAT hostun başlatdığı trafik üçün qonağın tunelini daşımır. Seqment adlarını və firewall qaydalarını bir yerdə saxlayın, işlək vəziyyətin snapshot-unu götürün və serverin müşahidə etdiyi mənbə ünvanını qeyd edin. Onda növbəti profil dəyişikliyi yenidən qurulmuş laboratoriya yerinə bir skript işinə başa gəlir.