VMware körpülü qonaq OpenVPN-dən sonra şəbəkəsini itirdi

Bir saat əvvəl körpülü və əlçatan olan qonaq indi hər şeydə vaxt aşımına düşür və heç kim onun parametrlərini redaktə etməyib. Hostda internet hələ də tunel vasitəsilə işləyir. Bu iki fakt birlikdə VPN-dən uzağa və hipervizora doğru işarə edir, çünki host və qonaq artıq eyni yoldan istifadə etmir. Buna səbəb olmaq üçün tək bir yeni virtual adapter kifayətdir.

Qonaq dəyişmədi, körpü dəyişdi

OpenVPN müştərisini Windows-da quraşdırmaq tunel qalxdıqda xidmətin bağlandığı virtual şəbəkə adapteri əlavə edir. Əməliyyat sistemi üçün bu, keçid vəziyyəti olan adi interfeysə və çox vaxt öz ünvanlarına bənzəyir. Bu, VMware-in onu körpü namizədi kimi qəbul etməsi üçün kifayətdir.

VMnet0 standart olaraq Avtomatik rejimə qoyulub, yəni hipervisor hər dəfə körpü qurarkən host adapterini seçir. Təzə quraşdırılmış virtual adapter bu hovuza qoşulur və əgər seçilərsə, qonağın göndərdiyi hər çərçivə fiziki kommutator portuna deyil, tunel cihazına gedir.

Körpünü bərkidin və ya qonağı marşrutlaşdırın

Birinci qol qonağın fiziki LAN-da bərabərhüquqlu iştirakçı olması lazım olduqda doğrudur: körpünün seçməsinə icazə verməyi dayandırın və adapteri açıq şəkildə adlandırın. İkinci qol qonağın korporativ tuneldən istifadə etməsi lazım olduqda tətbiq olunur və bu halda körpü heç vaxt düzgün dizayn deyildi, çünki körpülü qonaq hostun VPN marşrutunu miras almır.

Bunu ilk növbədə qərarlaşdırın, çünki iki cavab fərqli işlərə aparır. Sıranı tərsinə çevirmək heç vaxt körpülənməməli olan qonağa düzgün bərkidilmiş körpü yaradır.

Birinci qol üçün hostda Virtual Network Editor-u açın, VMnet0-ı seçin və Avtomatiki fiziki adapterlə əvəz edin. Bir neçə adapter varsa, avtomatik parametrlər siyahısından istifadə edin və heç vaxt qonaq trafiki daşımamalı olan hər şeyin işarəsini silin: OpenVPN TAP və ya Wintun cihazı, həmçinin Hyper-V, WSL, Docker və loopback adapterləri. Noutbukda həm kabel, həm də simsiz fiziki adapteri işarəli saxlayın, əks halda istifadəçi növbəti dəfə onu dokda qoşanda qonaq körpüsünü itirəcək.

Seçimi həll edən üç şərt

Körpünün ümumiyyətlə uyğun olub-olmadığı qonağın nə üçün olduğundan asılıdır. Qonaq LAN-da öz hostu kimi, öz ünvanı və öz giriş əlçatanlığı ilə görünməlidirsə, körpü düzgün modeldir və bərkitmə bütün düzəlişdir. Qonağın yalnız çıxış girişinə ehtiyacı varsa, yalnız host üçün şəbəkə və ya NAT daha sadədir və adapter dəyişikliklərinə davamlıdır.

Qonaq hostla eyni tuneldən istifadə etməlidirsə, nə körpü rejimi, nə də bərkidilmiş adapter kömək edir, çünki qonağın trafiki heç vaxt hostun marşrutlaşdırma qərarına daxil olmur. Bu hal hostda marşrutlaşdırılmış və ya tərcümə edilmiş yol tələb edir və adapter seçimi əhəmiyyətsiz olur.

VMware Player-in interfeysində şəbəkə redaktoru yoxdur, buna görə yalnız Player işlədən host bu parametrlərə çatmaq üçün ayrıca redaktora və ya Workstation quraşdırmasına ehtiyac duyur. Bu məhdudiyyət bəzən yanaşmanı təkbaşına müəyyən edir.

Nəticəni qonağın içindən oxuyun

Virtual NIC-i yenidən başladın və ya qonağı yenidən başladın ki, yenidən icarə istəsin. Sonra hostun konfiqurasiya etdiyini düşündüyünü deyil, həqiqətən nə aldığını oxuyun.

ipconfig /all
ip addr
ip route

Bu çıxışda iki sahəni oxuyun və qalanını hələlik nəzərə almayın. Şlüz LAN marşrutlaşdırıcısı olmalıdır və adapter təsviri tuneli deyil, VMware Ethernet cihazını göstərməlidir. 169.254.0.0/16 daxilində özünə təyin edilmiş ünvan heç bir DHCP serverinin cavab vermədiyini bildirir və tunel adapterinə qurulan körpü qonağın tərəfindən məhz belə görünür.

Başqa bir şeyi dəyişməzdən əvvəl daha bir fərq qeyd etməyə dəyər. Marşrutlaşdırıcıya çatan, lakin internetə çatmayan qonağın işlək körpüsü və yuxarıda problem var. Tunel aralığında ünvan alan qonaq hələ də yanlış cihaza qoşulub. TAP adapterini söndürmək iki halın heç biri üçün həll deyil, çünki OpenVPN xidmətinin ona ehtiyacı var.