Apakah VM Anda Memakai VPN Host? Uji dari Dalam Guest

Anda memeriksa IP publik host, tampilannya menunjukkan VPN, dan Anda menyimpulkan bahwa VM sudah tercakup. Kesimpulan itu tidak didukung oleh pengujian tersebut. Guest memiliki tabel routing sendiri, resolver sendiri, dan antarmuka sendiri, dan alamat keluar host tidak mengatakan apa pun tentang semuanya itu.

Pengujian harus dijalankan di dalam guest, dan harus menyebutkan apa yang diukur.

Mulai dari dalam guest, bukan dari browser host

Catat dulu mode jaringan hypervisor: NAT, bridged, host-only, atau macvtap. Dalam mode NAT, host merutekan lalu lintas guest, sehingga tunnel host bisa berlaku atau tidak tergantung pada cara klien memasang rute. Dalam mode bridged, guest adalah peer di LAN fisik dan tunnel host tidak relevan. Kedua mode itu menghasilkan jawaban yang berlawanan dari konfigurasi host yang sama.

Tuliskan mode tersebut sebelum Anda mengubah apa pun, karena mode itulah yang menentukan makna hasilnya.

Buat satu permintaan yang tujuannya Anda ketahui

Gunakan permintaan yang tidak berbahaya ke layanan yang melaporkan alamat sumber yang dilihatnya. Lalu periksa keputusan routing guest sendiri untuk tujuan itu: ip route get 203.0.113.5 mencetak antarmuka dan gateway yang akan dipakai guest.

Jika antarmukanya adalah NIC normal guest, lalu lintas itu tidak melewati tunnel di dalam guest.

Adapter kedua, pengaturan proxy, atau klien VPN di sisi guest dapat mengubah jawaban untuk satu aplikasi dan bukan untuk aplikasi lain. Ujilah aplikasi yang benar-benar Anda pedulikan, bukan permintaan umum dari shell.

Periksa resolver secara terpisah

Alamat keluar yang berubah tidak memberi tahu Anda resolver mana yang menangani nama host itu. Kueri nama tersebut secara eksplisit dengan alat yang sesuai dengan platform, dan catat server mana yang menjawab. Split DNS berarti pertanyaan resolver dan pertanyaan routing punya jawaban berbeda.

Keduanya bisa menyimpang ke arah mana pun, dan penyimpangan itulah yang sering menjadi bug sebenarnya.

Pada host systemd, resolvectl query menyebutkan antarmuka dan server DNS di balik jawaban itu. Penyiapan yang lebih lama menampilkan server tersebut di keluaran dig. Bagaimanapun, intinya adalah melihat server mana yang menjawab, bukan sekadar apakah ada jawaban yang datang.

Uji kebijakan kegagalan, bukan hanya keberhasilan

Jika persyaratannya adalah tidak ada lalu lintas yang keluar di luar tunnel, permintaan yang berhasil tidak membuktikan apa pun. Gunakan uji kegagalan terkendali yang didukung klien: hentikan tunnel dengan cara yang didukung dan lihat apakah permintaan guest yang baru diblokir. Jangan menganggap kill switch klien host mencakup setiap pengaturan penerusan virtual. Cakupan yang didokumentasikan hanyalah hal yang bisa Anda andalkan.

Guest yang kembali ke NIC fisik saat tunnel putus sedang melakukan tepat apa yang diizinkan mode NAT.

Catat mode dan cakupannya

Tuliskan mode hypervisor, antarmuka dan rute guest, resolver, serta aplikasi yang Anda uji. Tambahkan tanggalnya, karena pemulihan snapshot atau pembaruan hypervisor dapat mengubah keempatnya.

Jika IPv4 mengikuti tunnel, katakan demikian. Jangan memperluas klaim ke IPv6, namespace lain, atau VM lain di jaringan yang berbeda.