Adakah VM Anda Menggunakan VPN Hos? Uji dari Dalam Guest

Anda menyemak IP awam hos, ia menunjukkan VPN, dan anda membuat kesimpulan bahawa VM dilindungi. Kesimpulan itu tidak disokong oleh ujian ini. Guest mempunyai jadual penghalaan sendiri, penyelesai sendiri dan antara muka sendiri, dan alamat keluar hos tidak memberitahu apa-apa tentangnya.

Ujian mesti dijalankan di dalam guest, dan ia mesti menyatakan apa yang diukur.

Mulakan di dalam guest, bukan di pelayar hos

Rekod dahulu mod rangkaian hypervisor: NAT, bridged, host-only atau macvtap. Dalam mod NAT hos menghalakan trafik guest, jadi terowong hos mungkin terpakai atau tidak bergantung pada cara klien memasang laluan. Dalam mod bridged guest ialah rakan setara pada LAN fizikal dan terowong hos tidak relevan. Kedua-dua mod ini memberikan jawapan bertentangan daripada konfigurasi hos yang sama.

Tuliskan mod itu sebelum anda mengubah apa-apa, kerana ia menentukan apa yang boleh dimaksudkan oleh keputusan itu.

Buat satu permintaan yang destinasinya anda ketahui

Gunakan permintaan tidak berbahaya kepada perkhidmatan yang melaporkan alamat sumber yang dilihatnya. Kemudian periksa keputusan penghalaan guest sendiri untuk destinasi itu: ip route get 203.0.113.5 mencetak antara muka dan get laluan yang akan digunakan oleh guest.

Jika antara muka itu NIC biasa guest, trafik itu tidak melalui terowong di dalam guest.

Penyesuai kedua, tetapan proksi atau klien VPN di sebelah guest boleh mengubah jawapan untuk satu aplikasi dan bukan yang lain. Uji aplikasi yang benar-benar anda pedulikan, bukan permintaan generik daripada shell.

Periksa penyelesai secara berasingan

Alamat keluar yang berubah tidak memberitahu anda penyelesai mana yang mengendalikan nama hos itu. Tanya nama itu secara eksplisit dengan alat yang sepadan dengan platform, dan catat pelayan mana yang menjawab. Split DNS bermaksud soalan penyelesai dan soalan penghalaan mempunyai jawapan yang berbeza.

Kedua-duanya boleh menyimpang ke mana-mana arah, dan penyimpangan itulah yang sering menjadi pepijat sebenar.

Pada hos systemd, resolvectl query menamakan antara muka dan pelayan DNS di sebalik jawapan itu. Persediaan lama menunjukkan pelayan itu dalam output dig. Apa pun caranya, intinya ialah melihat pelayan mana yang menjawab, bukan sekadar sama ada jawapan tiba.

Uji dasar kegagalan, bukan hanya kejayaan

Jika keperluannya ialah tiada trafik keluar di luar terowong, permintaan yang berjaya tidak membuktikan apa-apa. Gunakan ujian kegagalan terkawal yang disokong klien: hentikan terowong dengan cara yang disokong dan lihat sama ada permintaan guest yang baharu disekat. Jangan anggap kill switch klien hos meliputi setiap susunan pemajuan maya. Skopnya yang didokumenkan ialah satu-satunya perkara yang boleh anda bergantung pada.

Guest yang kembali ke NIC fizikal apabila terowong terputus sedang melakukan tepat apa yang dibenarkan oleh mod NAT.

Rekod mod dan skopnya

Tuliskan mod hypervisor, antara muka dan laluan guest, penyelesai, dan aplikasi yang anda uji. Tambah tarikh, kerana pemulihan snapshot atau kemas kini hypervisor boleh mengubah kesemua empatnya.

Jika IPv4 mengikut terowong, katakan begitu. Jangan lanjutkan dakwaan itu kepada IPv6, ruang nama lain atau VM lain pada rangkaian yang berbeza.