Jalankan VPN pada hos atau di dalam VM? Panduan keputusan

Membina terowong di dalam tetamu dan membinanya pada hos kedua-duanya menukar alamat yang dilaporkan pelayar, dan di situlah persamaannya berakhir. Terowong milik tetamu menyimpan kuncinya, laluan lalainya dan penyelesainya di dalam kernel tetamu, sementara hos memajukan paket tersulit ke satu alamat jauh. Terowong milik hos ialah imej cermin: klien hos memegang sesi dan menggunakan laluan serta dasar, dan tetamu meminjam apa yang keluar. Pilih pemilik yang salah dan setiap gejala kemudian akan menghantar anda ke mesin yang salah. Dua arahan menyelesaikan persoalan itu dalam kira-kira satu minit, dan selebihnya panduan ini ialah apa yang perlu dilakukan dengan jawapannya.

Tentukan pemiliknya sebelum anda menyentuh klien

Peraturannya ialah tentang di mana teks sifer dihasilkan, bukan tentang mesin mana yang memaparkan ikon VPN. Jika tetamu menghasilkannya, tetamu memerlukan laluan yang berfungsi ke pelayan VPN dan tiada apa-apa lagi daripada hos. Jika hos menghasilkannya, tetamu memerlukan laluan hos itu untuk bertahan daripada apa-apa dasar yang dikenakan oleh klien hos ke atas trafik tempatan.

Tiga soalan biasanya memilih penempatan untuk anda. Perlukah trafik tetamu bertahan melalui klien korporat pada hos? Maka terowong ada di dalam tetamu. Perlukah beberapa tetamu satu kelayakan dan satu alamat keluar? Maka ia ada pada hos, dengan pemajuan dikonfigurasi dengan sengaja. Perlukah trafik tetamu kekal sepenuhnya di luar VPN hos? Maka terowong dalam tetamu ialah satu-satunya susunan yang memberikannya secara pembinaan.

Catat jawapannya dalam satu baris di sebelah nama VM: guest-owned atau host-owned. Dalam makmal enam mesin, catatan itu menjimatkan lebih banyak masa daripada mana-mana langkah di bawah, kerana ia menghalang anda daripada menyiasat terowong yang tidak pernah berada dalam mesin yang anda log masuk.

WSL1 dan WSL2 ialah kes yang bertentangan

WSL1 bukan mesin maya, jadi persoalan penempatan kebanyakannya hilang. Binari Linuxnya berjalan terhadap tindanan rangkaian Windows melalui lapisan terjemahan, dan klien VPN Linux tiada antara muka bebas untuk dikonfigurasi. Susunan yang berfungsi ialah terowong di sebelah Windows, dengan pengedaran menggunakan hasilnya tanpa memiliki apa-apa.

WSL2 ialah sebaliknya. Ia menjalankan kernel sebenar dalam VM utiliti ringan di belakang suis maya Hyper-V, dan ruang alamatnya di-NAT melalui penyesuai di sebelah hos. Oleh itu klien Linux di dalam pengedaran berkelakuan seperti pada kotak Linux fizikal: ia mencipta tun0 atau wg0, memasang laluannya sendiri, dan berfungsi. Kegagalan tinggal di sebelah hos. Apabila klien VPN Windows menyambung dengan dasar yang menyekat trafik pada rangkaian tempatan, ia menganggap subnet WSL2 sebagai rangkaian tempatan tidak dipercayai dan memotong laluan NAT. Pengedaran kemudian kehilangan DNS dan akses keluar sementara terowongnya sendiri masih sihat: wg show melaporkan jabat tangan, ip route kelihatan betul, dan curl tergantung.

Pembaikan mana yang boleh anda gunakan bergantung pada binaan Windows. Yang lebih lama ialah pengecualian dalam klien hos untuk subnet WSL, ditambah di bawah tetapan rangkaian tempatan atau terowong berpecah klien. Yang lebih baharu, pada binaan Windows 11 yang menyokongnya, ialah rangkaian bercermin: letakkan networkingMode=mirrored dalam bahagian [wsl2] pada %UserProfile%\.wslconfig, jalankan wsl --shutdown, dan pengedaran berkongsi antara muka hos dan bukannya subnet NAT peribadi. Mod bercermin juga mengubah kelakuan localhost dan port masuk, jadi anggap ia sebagai penghijrahan dan bukan suis.

NAT, jambatan dan apa yang hos boleh lihat

Di bawah NAT, paket terowong tetamu dialamatkan ke alamat awam pelayan VPN dan keluar melalui penyesuai hos sebagai UDP atau TCP tersulit. Hos melihat satu aliran dan bilangan baitnya, tiada apa-apa tentang destinasi di dalamnya. Di bawah penyesuai berjambatan tetamu mempunyai identiti lapis 2 sendiri pada LAN fizikal, mengambil pajakan DHCP sendiri, dan kelihatan kepada mana-mana dasar berasaskan MAC sebagai peranti kedua. Tiada mod membenarkan hos membaca muatan terowong; tetamu berjambatan hanya jauh lebih kelihatan kepada rangkaian di sekelilingnya.

Pengasingan juga mempunyai lantai. Tetamu tidak boleh menyembunyikan diri daripada mesin yang memiliki memorinya, dan sesiapa yang mengawal hos boleh membaca kunci daripada RAM tetamu. Apa yang diberikan terowong dalam tetamu ialah sempadan penghalaan dan sempadan perisian hasad, bukan perlindungan daripada orang yang memegang komputer riba itu. Mod penyesuai yang didokumenkan wajar dibuka semasa anda memilih, kerana mod mengubah apa yang dilihat hos dan apa yang dilihat LAN.

Panduan: letakkan, konfigurasikan, buktikan

Jalankan keempat-empat semakan ini mengikut urutan dalam shell tetamu baharu, dan berhenti pada yang pertama tidak sepadan dengan pemilik yang anda catat.

1. ip route get 1.1.1.1 yang memulangkan tun0 atau wg0 bermaksud milik tetamu, dan eth0 dengan hop seterusnya peribadi bermaksud milik hos.
2. resolvectl query example.com, atau baca /etc/resolv.conf di tempat tetamu tidak menjalankan perkhidmatan penyelesai. Terowong yang membawa trafik tetapi bukan DNS ialah keadaan separuh dikonfigurasi yang paling biasa.
3. Bandingkan keluaran: curl -4 -s https://ifconfig.me di dalam tetamu berbanding curl.exe -4 -s https://ifconfig.me pada hos. Alamat berbeza bermaksud tetamu memiliki terowong, dan hos pada VPN dengan tetamu yang menunjukkan ISP rumah ialah kes tidak mewarisi apa-apa.
4. Ulang kedua-duanya dengan -6. Terowong hanya v4 membocorkan v6 melainkan klien menyekat atau menghalakannya, dan banyak klien membiarkan v6 pada antara muka fizikal secara lalai.

Untuk reka bentuk pintu hos, di mana beberapa tetamu berkongsi satu terowong, hos mesti memajukan dan menterjemah. Pada hos Linux itu tiga bahagian, dan tetamu jatuh senyap kembali ke laluan biasa apabila mana-mana daripadanya tiada:

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 sebelah WireGuard, AllowedIPs rakan hos mesti merangkumi subnet tetamu, contohnya 192.168.122.0/24, jika tidak paket balasan tidak akan pernah tiba dan persediaan kelihatan seperti masalah tembok api. Hos Windows mencapai hasil yang sama dengan Perkongsian Sambungan Internet atau peraturan NAT pada suis Hyper-V, dan memerlukan semakan laluan balik yang sama.

Apabila susun atur masih terbuka, jadual ini merangkumi susunan yang paling kerap muncul:

Dua terowong, dua tetamu, dan konflik antara mereka

Apabila anda memerlukan dua keluaran serentak, corak yang bertahan ialah satu terowong bagi setiap tetamu. Setiap VM menyimpan laluan lalai dan penyelesainya sendiri, hos kekal pada rangkaian biasa, dan kedua-dua terowong tidak pernah bertengkar atas jadual penghalaan yang sama. Menjambatani dua tetamu juga tidak menggabungkan laluan mereka: rangkaian maya menyediakan laluan, dan setiap klien masih perlu diberitahu bahawa trafik tempatan ini boleh memintas terowong.

Menjalankan terowong hos dan terowong tetamu bersama-sama adalah sah, dan penyarangan yang disengajakan kadangkala tepat apa yang anda mahukan, dengan tetamu keluar melalui terowongnya sendiri dan terowong itu keluar melalui terowong hos. Apa yang menjadikannya gangguan ialah tiada siapa mencatat titik hujung mana yang perlu dicapai melalui lapisan mana. Simpan senarai dua lajur bagi destinasi dan pemilik, dan konflik laluan menjadi carian dan bukannya sehari penemuan.

Sahkan, kemudian biarkan pemulihan pada pemiliknya

Uji dari dalam tetamu dengan proses aplikasi baharu: trafik, penyelesaian nama, kedua-dua keluarga alamat, dan apa yang berlaku apabila terowong jatuh. Ikon VPN hos tidak mengatakan apa-apa tentang liputan tetamu, dan itulah pengesahan palsu yang paling biasa di seluruh bidang ini.

Pemulihan juga milik pemiliknya. Terowong milik tetamu dipulihkan oleh klien tetamu itu sendiri dan laluan yang ditulisnya. Reka bentuk milik hos dipulihkan oleh urutan but hos, dan peraturan pemajuan tidak bertahan selepas but semula melainkan unit atau tugas permulaan menggunakannya semula. Snapshot yang dipulihkan ialah penggunaan, bukan pembatalan, kerana ia mengembalikan kelayakan lama dan laluan lama bersama cakera. Sebelum menyatakan kerja selesai, sahkan pemiliknya masih sepadan dengan baris yang anda catat, DNS dan kedua-dua keluarga alamat diselesaikan di dalam tetamu, terowong mati meninggalkan rangkaian yang boleh digunakan dan bukannya lubang hitam, dan but semula atau pemulihan snapshot menghasilkan keadaan yang sama.