VM host VPN-dən istifadə edirmi? Qonağın içindən yoxlayın

Hostun ictimai IP-sini yoxlayırsınız, orada VPN görünür və VM-in əhatə olunduğu qənaətinə gəlirsiniz. Bu qənaəti test təsdiqləmir. Qonağın öz marşrut cədvəli, öz resolveri və öz interfeysləri var, və hostun çıxış ünvanı onlar barədə heç nə demir.

Test qonağın içində aparılmalı və nəyi ölçdüyünü adlandırmalıdır.

Hostun brauzerində deyil, qonağın içində başlayın

Əvvəlcə hipervisorun şəbəkə rejimini qeyd edin: NAT, bridged, host-only və ya macvtap. NAT rejimində host qonağın trafikini yönləndirir, buna görə hostun tuneli müştərinin marşrutları necə qurmasından asılı olaraq tətbiq oluna da bilər, olunmaya da. Bridged rejimində qonaq fiziki LAN-da bərabər iştirakçıdır və hostun tuneli əhəmiyyətsizdir. Bu iki rejim eyni host konfiqurasiyasından əks cavablar verir.

Heç nəyi dəyişməzdən əvvəl rejimi yazın, çünki nəticənin nə məna verə biləcəyini o müəyyən edir.

Təyinatını bildiyiniz bir sorğu göndərin

Gördüyü mənbə ünvanını bildirən bir xidmətə zərərsiz sorğu göndərin. Sonra qonağın həmin təyinat üçün öz marşrut qərarını yoxlayın: ip route get 203.0.113.5 qonağın istifadə edəcəyi interfeysi və şlüzü çap edir.

Interfeys qonağın adi NIC-idirsə, trafik qonağın içindəki tuneldən keçmir.

İkinci adapter, proxy parametri və ya qonaq tərəfdəki VPN müştərisi bir tətbiq üçün cavabı dəyişə bilər, digəri üçün yox. Əslində əhəmiyyət verdiyiniz tətbiqi sınayın, shell-dən gələn ümumi sorğunu yox.

Resolveri ayrıca yoxlayın

Dəyişmiş çıxış ünvanı host adı ilə hansı resolverin işlədiyini demir. Adı platformaya uyğun alətlə açıq şəkildə sorğulayın və hansı serverin cavab verdiyini qeyd edin. Bölünmüş DNS o deməkdir ki, resolver sualı ilə marşrut sualının cavabları fərqlidir.

Bu ikisi hər iki istiqamətdə fərqlənə bilər və fərq çox vaxt əsl xəta olur.

systemd hostunda resolvectl query cavabın arxasındakı interfeysi və DNS serverini adlandırır. Köhnə quraşdırmalar serveri dig çıxışında göstərir — hər halda məqsəd hansı serverin cavab verdiyini görməkdir, sadəcə cavabın gəlib-gəlmədiyini yox.

Yalnız uğuru deyil, uğursuzluq siyasətini sınayın

Tələb tuneldən kənara heç bir trafikin çıxmamasıdırsa, uğurlu sorğu heç nə sübut etmir. Müştərinin dəstəklənən nəzarətli uğursuzluq testindən istifadə edin: tuneli dəstəklənən üsulla dayandırın və qonaqdan gələn yeni sorğunun bloklanıb-bloklanmadığına baxın. Host müştərisinin kill switch-inin hər virtual yönləndirmə quruluşunu əhatə etdiyini güman etməyin. Yalnız sənədləşdirilmiş əhatə dairəsinə arxalana bilərsiniz.

Tunel düşəndə fiziki NIC-ə qayıdan qonaq məhz NAT rejiminin icazə verdiyini edir.

Rejimi və əhatə dairəsini qeyd edin

Hipervisor rejimini, qonağın interfeysini və marşrutunu, resolveri və sınaqdan keçirdiyiniz tətbiqi yazın. Tarixi də əlavə edin, çünki snapshot bərpası və ya hipervisor yeniləməsi dördünü də dəyişə bilər.

IPv4 tunelə uyğun gəldisə, bunu deyin. İddianı IPv6-ya, başqa ad məkanına və ya başqa şəbəkədəki başqa VM-ə genişləndirməyin.