Menjalankan VPN di host atau di dalam VM? Buku pedoman keputusan

Membangun tunnel di dalam tamu dan membangunnya di host sama-sama mengubah alamat yang dilaporkan peramban, dan di situlah kemiripannya berakhir. Tunnel milik tamu menyimpan kuncinya, rute defaultnya, dan resolver-nya di dalam kernel tamu, sementara host meneruskan paket terenkripsi ke satu alamat jarak jauh. Tunnel milik host adalah cermin kebalikannya: klien host memegang sesi dan menerapkan rute serta kebijakan, dan tamu meminjam apa pun yang keluar. Pilih pemilik yang salah dan setiap gejala berikutnya akan mengirim Anda ke mesin yang salah. Dua perintah menyelesaikan pertanyaan itu dalam sekitar satu menit, dan sisa buku pedoman ini adalah apa yang harus dilakukan dengan jawabannya.

Tentukan pemiliknya sebelum Anda menyentuh klien

Aturannya menyangkut di mana ciphertext dihasilkan, bukan mesin mana yang menampilkan ikon VPN. Jika tamu yang menghasilkannya, tamu memerlukan rute yang berfungsi ke server VPN dan tidak memerlukan apa pun dari host. Jika host yang menghasilkannya, tamu memerlukan jalur host itu tetap hidup apa pun kebijakan yang diterapkan klien host pada lalu lintas lokal.

Tiga pertanyaan biasanya memilih penempatan untuk Anda. Apakah lalu lintas tamu harus bertahan melewati klien korporat di host? Maka tunnel ada di dalam tamu. Apakah beberapa tamu memerlukan satu kredensial dan satu alamat keluar? Maka tunnel ada di host, dengan penerusan yang dikonfigurasi dengan sengaja. Apakah lalu lintas tamu harus tetap sepenuhnya di luar VPN host? Maka tunnel di tamu adalah satu-satunya susunan yang memberikannya secara konstruktif.

Catat jawabannya dalam satu baris di samping nama VM: guest-owned atau host-owned. Di laboratorium berisi enam mesin, catatan itu menghemat lebih banyak waktu daripada langkah mana pun di bawah, karena mencegah Anda menelusuri tunnel yang tidak pernah ada di mesin yang Anda masuki.

WSL1 dan WSL2 adalah kasus yang berlawanan

WSL1 bukan mesin virtual, jadi pertanyaan penempatan sebagian besar menguap. Biner Linux-nya berjalan terhadap tumpukan jaringan Windows melalui lapisan penerjemahan, dan klien VPN Linux tidak memiliki antarmuka independen untuk dikonfigurasi. Susunan yang berfungsi adalah tunnel di sisi Windows, dengan distribusi memakai hasilnya tanpa memiliki apa pun.

WSL2 adalah kebalikannya. Ia menjalankan kernel sungguhan di VM utilitas ringan di belakang sakelar virtual Hyper-V, dan ruang alamatnya di-NAT melalui adaptor di sisi host. Karena itu klien Linux di dalam distribusi berperilaku seperti pada kotak Linux fisik: ia membuat tun0 atau wg0, memasang rutenya sendiri, dan berfungsi. Kegagalannya tinggal di sisi host. Saat klien VPN Windows tersambung dengan kebijakan yang memblokir lalu lintas di jaringan lokal, ia memperlakukan subnet WSL2 sebagai jaringan lokal yang tidak tepercaya dan memutus jalur NAT. Distribusi lalu kehilangan DNS dan akses keluar sementara tunnel-nya sendiri masih sehat: wg show melaporkan handshake, ip route tampak benar, dan curl menggantung.

Perbaikan mana yang bisa Anda pakai bergantung pada build Windows. Yang lebih lama adalah pengecualian di klien host untuk subnet WSL, ditambahkan di pengaturan jaringan lokal atau tunnel terpisah klien. Yang lebih baru, pada build Windows 11 yang mendukungnya, adalah jaringan tercermin: letakkan networkingMode=mirrored di bagian [wsl2] pada %UserProfile%\.wslconfig, jalankan wsl --shutdown, dan distribusi berbagi antarmuka host alih-alih subnet NAT privat. Mode tercermin juga mengubah perilaku localhost dan port masuk, jadi perlakukan itu sebagai migrasi, bukan tombol.

NAT, jembatan, dan apa yang bisa dilihat host

Di bawah NAT, paket tunnel tamu dialamatkan ke alamat publik server VPN dan keluar melalui adaptor host sebagai UDP atau TCP terenkripsi. Host melihat satu aliran dan jumlah byte-nya, tidak tahu apa pun tentang tujuan di dalamnya. Di bawah adaptor berjembatan, tamu memiliki identitas lapis 2 sendiri di LAN fisik, mengambil sewa DHCP sendiri, dan tampak bagi kebijakan berbasis MAC mana pun sebagai perangkat kedua. Tidak ada mode yang membiarkan host membaca muatan tunnel; tamu berjembatan hanya jauh lebih terlihat oleh jaringan di sekitarnya.

Ada juga batas bawah untuk isolasi. Tamu tidak dapat bersembunyi dari mesin yang memiliki memorinya, dan siapa pun yang mengendalikan host dapat membaca kunci dari RAM tamu. Yang diberikan tunnel di tamu adalah batas perutean dan batas malware, bukan perlindungan dari orang yang memegang laptop itu. Mode adaptor yang terdokumentasi layak dibuka selama Anda memilih, karena mode mengubah apa yang dilihat host dan apa yang dilihat LAN.

Buku pedoman: tempatkan, konfigurasikan, buktikan

Jalankan keempat pemeriksaan ini secara berurutan di shell tamu yang baru, dan berhenti pada pemeriksaan pertama yang tidak cocok dengan pemilik yang Anda catat.

1. ip route get 1.1.1.1 yang mengembalikan tun0 atau wg0 berarti milik tamu, dan eth0 dengan hop berikutnya privat berarti milik host.
2. resolvectl query example.com, atau bacalah /etc/resolv.conf di tempat tamu tidak menjalankan layanan resolver. Tunnel yang membawa lalu lintas tetapi bukan DNS adalah keadaan setengah terkonfigurasi yang paling umum.
3. Bandingkan keluaran: curl -4 -s https://ifconfig.me di tamu dengan curl.exe -4 -s https://ifconfig.me di host. Alamat berbeda berarti tamu memiliki tunnel, dan host di VPN dengan tamu yang menampilkan ISP rumah adalah kasus tidak mewarisi apa pun.
4. Ulangi keduanya dengan -6. Tunnel hanya v4 membocorkan v6 kecuali klien memblokir atau merutekannya, dan banyak klien membiarkan v6 di antarmuka fisik secara default.

Untuk rancangan gerbang host, di mana beberapa tamu berbagi satu tunnel, host harus meneruskan dan menerjemahkan. Di host Linux itu tiga bagian, dan tamu diam-diam kembali ke rute biasa saat salah satunya hilang:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Di sisi WireGuard, AllowedIPs rekan host harus memuat subnet tamu, misalnya 192.168.122.0/24, jika tidak paket balasan tidak akan pernah tiba dan penyetelan tampak seperti masalah firewall. Host Windows mencapai hasil yang sama dengan Berbagi Koneksi Internet atau aturan NAT pada sakelar Hyper-V, dan memerlukan pemeriksaan jalur balik yang sama.

Saat tata letaknya masih terbuka, tabel ini mencakup susunan yang paling sering muncul:

Dua tunnel, dua tamu, dan konflik di antara keduanya

Saat Anda memerlukan dua keluaran sekaligus, pola yang bertahan adalah satu tunnel per tamu. Setiap VM menyimpan rute default dan resolver-nya sendiri, host tetap di jaringan biasa, dan kedua tunnel tidak pernah berselisih atas tabel perutean yang sama. Menjembatani dua tamu juga tidak menyatukan rute mereka: jaringan virtual menyediakan jalur, dan setiap klien masih harus diberi tahu bahwa lalu lintas lokal ini boleh melewati tunnel.

Menjalankan tunnel host dan tunnel tamu bersama-sama itu sah, dan penyarangan yang disengaja kadang justru yang Anda inginkan, dengan tamu keluar melalui tunnel-nya sendiri dan tunnel itu keluar melalui milik host. Yang mengubahnya menjadi gangguan adalah tidak ada yang mencatat titik ujung mana harus dicapai melalui lapisan mana. Simpan daftar dua kolom berisi tujuan dan pemilik, dan konflik rute menjadi pencarian alih-alih seharian menemukan.

Verifikasi, lalu simpan pemulihan pada pemiliknya

Uji dari dalam tamu dengan proses aplikasi yang baru: lalu lintas, penyelesaian nama, kedua keluarga alamat, dan apa yang terjadi saat tunnel putus. Ikon VPN di host tidak mengatakan apa pun tentang cakupan tamu, dan itulah konfirmasi palsu yang paling umum di seluruh bidang ini.

Pemulihan juga milik pemiliknya. Tunnel milik tamu dipulihkan oleh klien tamu itu sendiri dan rute yang ditulisnya. Rancangan milik host dipulihkan oleh urutan boot host, dan aturan penerusan tidak bertahan setelah reboot kecuali sebuah unit atau tugas mulai menerapkannya lagi. Snapshot yang dipulihkan adalah penerapan, bukan pembatalan, karena ia mengembalikan kredensial lama dan rute lama bersama disknya. Sebelum menyatakan pekerjaan selesai, pastikan pemiliknya masih cocok dengan baris yang Anda catat, DNS dan kedua keluarga alamat terselesaikan di dalam tamu, tunnel yang mati meninggalkan jaringan yang bisa dipakai alih-alih lubang hitam, dan reboot atau pemulihan snapshot menghasilkan keadaan yang sama.