VirtualBox NAT və ya körpü: VM-in VPN-i harada bitir

Virtual maşın VPN müştərisi işlədəndə iki fərqli sual eyni vaxtda ortaya çıxır və onların cavabları fərqlidir. Birincisi, qonağın içindəki tunelin hostu qoruyub-qorumamasıdır, ikincisi isə hostdakı tunelin qonağı əhatə edib-etməməsidir. Adapter rejimi hər ikisini həll edir, VPN proqramından daha çox. NAT adapteri hostu görünən son nöqtə edir, körpü adapteri isə qonağı öz ünvanı ilə şəbəkəyə qoyur.

Şifrəli sessiyanı əslində kim sonlandırır

Şifrəli sessiya onu sonlandıran maşına aiddir və müştəri VM-in içində işləyəndə bu qonaqdır. Yalnız qonağın virtual adapterinə daxil olan trafik o tuneldən keçir və hipervisor heç vaxt başqa maşını özü qonaqdan yönləndirmir. Buna görə qonaq işlək tunel saxlaya bilər, halbuki host açıq şəbəkədə gəzir. Əksi simmetrik deyil və bu asimmetriya əksər təlimatların səhv saldığı hissədir.

Xarici şəbəkənin hansı ünvanı gördüyü adapter rejiminin cavablandırdığı sualdır. Bu həll olunduqdan sonra əhatə bir siyasət məsələsi olmaqdan çıxıb mexaniki məsələyə çevrilir. Aşağıdakı hər şey bu iki faktdan irəli gəlir.

NAT qonağı hosta bənzəyənə qədər yenidən yazır

NAT ilə hipervisor qonağın hər paketini ilk kommutatora çatmazdan əvvəl hostun ünvanına yenidən yazır. Sonra bu trafik hostun öz şəbəkə yığınına verilir və orada hostun marşrut cədvəlinə uyğun gedir, o cümlədən hostdakı tunelin sahib olduğu default marşrut. Beləliklə NAT qonağı heç bir konfiqurasiya olmadan host tuneli ilə əhatə olunur və bu, qonaqdan hosta istiqamətinin təklif etdiyinin əksidir.

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

Öz müştərisini işlədən qonaq o tuneli qonağın içində sonlandırır, şifrəli trafik isə həmin yenidən yazmadan çıxır, buna görə host tətbiqləri öz yolunu və öz çıxış ünvanını saxlayır. VirtualBox bu rejimdə ad həllinə də sahibdir və --natdnshostresolver1 aktiv olmayanda qonaq sorğularını öz mühərriki ilə ötürür. Onu aktivləşdirmək qonağın axtarışlarını hostun həlledicine verir; bu, hostun öz görünüşü doğru olduqda həlli düzəldir və eyni dərəcədə yalnız tunelin içində mövcud ola bilən həlledici ötürür. Parametri dəyişməzdən əvvəl VM söndürülməlidir və parametr qonağın proqramına deyil, adapterə aiddir.

Körpü qonağa öz icarəsini və öz məruz qalmasını verir

Körpü qonağın kadrlarını fiziki seqmentə ötürür, buna görə DHCP ona icarə verir və şəbəkə onu ayrı host kimi qəbul edir. Hər körpülənmiş qonaq öz default marşrutu ilə müstəqil tunel saxlaya bilər və hostun cədvəli heç dəyişmir. Qiyməti məruz qalmadır: qonaq yayımlara cavab verir, qonşu cədvəllərində görünür və kommutator portunun təhlükəsizliyi ilə simsiz müştəri izolyasiyasına tabe olur. Host tuneli bu quruluşu da əhatə etmir, çünki qonağın kadrları heç vaxt host yığınından keçmir.

NAT halından bu fərqi bir nəticə kimi buraxmaq əvəzinə açıq deməyə dəyər. Körpülənmiş qonaq trafiki tuneldən istifadə etməli olduqda öz müştərisinə və öz etimad məlumatlarına ehtiyac duyur. Qonaq yerli şəbəkədən görünməz qalmalı olduqda NAT və ya idarə olunan marşrutlaşdırma ilə yalnız daxili şəbəkə daha yaxşı dizayndır.

Qonaq niyə hostun şlüzü ola bilməz

Qonağın tunelini hosta borc verməyin iki böyük hipervisordan heç birində dəstəklənən açarı yoxdur. Hostun qonağın tunelinə marşrutu və ona yönələn tərcümə qaydası yoxdur, buna görə qonaq və host trafiki ayrı sahibləri olan ayrı axınlar olaraq qalır. Bu istiqamət adapter rejimindən asılı olmayaraq uğursuz olur.

İşlək əvəzlər yönləndirmələr və proksilərdir. SSH lokal yönləndirməsi hostun öz loopbackinə qoşulmasına imkan verir, qonaq isə axını tunelə daşıyır; bu, ikinci müştəri quraşdırmadan TCP xidmətlərini əhatə edir. Hostun öz IP trafikini bunun əvəzinə qonağın tunelindən istifadə etdirmək qonağın içində marşrutlaşdırıcı, hostda isə açıq marşrut və tərcümə tələb edir. Bu, kvadrat işarəsi deyil, kiçik bir şəbəkə dizaynıdır və geri yol üçün plan tələb edir. Qonaq yalnız müştərini işlətmək üçün varsa, müştərini hosta qoyun və əlavə addımı silin.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Həlledicilər və marşrutlar sərhədi keçmir

DNS opsiyanı qəbul edən adapteri izləyir, buna görə qonaq hostun tunel həlledicisini miras almır və host heç vaxt qonağa ötürülən serveri öyrənmir. Ötürülən dhcp-option DNS dəyərləri onları qəbul edən interfeysə aiddir, buna görə müştərisi olmayan körpülənmiş qonaq daxili adları həll edə bilmir. NAT qonağı adətən hipervisorun DNS idarəetməsindən istifadə edir və fərq hər mühitdə bir əmrlə görünür.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

Hostun ardınca getdiyini fərz etməzdən əvvəl həlledici və marşrutu qonağın içində oxuyun. Daxili adlar orada həll olunmalıdırsa, tunel həlledicisini qonağın öz adapterinə əlavə edin, sonra yalnız tunelin arxasında mövcud olan adla yoxlayın. Hər VM üçün adapter rejimini, tunelin sahibini və həlledicinin mənbəyini qeyd edin, çünki bu üç fakt demək olar ki, hər sonrakı suala cavab verir. Digər hipervisorlar rejimlərin adını dəyişir və prinsipi toxunulmaz saxlayır.