Cara menghantar hanya satu subnet peribadi melalui VPN

Satu subnet peribadi melalui terowong dan semua yang lain melalui laluan biasa anda ialah permintaan kecil dengan banyak cara untuk tersalah. Yang menentukan hasil bukan kotak semak bernama split tunneling, tetapi di mana keputusan itu dikuatkuasakan: jadual laluan klien sendiri, laluan yang ditolak pelayan, atau dasar yang dirundingkan kedua-dua hujung. Pilih lapisan yang salah dan anda mendapat sama ada terowong penuh yang tidak pernah anda mahukan, atau laluan ke terowong yang pihak lain enggan terima. Saya menggunakan ujian tiga syarat sebelum membuka sebarang konfigurasi, kemudian memilih salah satu mekanisme di bawah.

Tiga syarat yang menentukan reka bentuk

Pertama, anda perlukan awalan dan topeng yang tepat daripada pemilik rangkaian. Rangkaian 10.x bukan awalan; 10.20.0.0/16 ialah awalan. Pastikan ia tidak bertindih dengan LAN rumah anda, jambatan Docker atau VPN lain yang anda jalankan, kerana pertindihan menjadikan laluan kabur dan kernel memilih entri yang anda tidak maksudkan.

Kedua, siapa yang menjawab trafik balasan. Menghalakan paket ke dalam terowong hanya membawanya ke pelayan VPN. Jika subnet berada di belakang penghala lain yang tiada laluan balik ke kumpulan klien anda, pelayan mesti menyamar trafik itu, atau penghala itu mesti mempelajari kumpulan anda. Tiada laluan di sebelah klien yang membaiki laluan balik yang hilang.

Ketiga, titik penguatkuasaan. Sesetengah klien memasang laluan dan sistem pengendalian melakukan selebihnya. Yang lain merundingkan dasar, dan dasar yang tidak diterima get laluan tidak menghasilkan terowong langsung: paket digugurkan tanpa ralat yang jelas. Tentukan yang mana satu kes anda sebelum menulis apa-apa.

WireGuard: AllowedIPs ialah jadual laluan

Pada klien, AllowedIPs menyenaraikan destinasi yang boleh masuk ke terowong, dan wg-quick menukar setiap entri menjadi laluan biasa. Jadi separuh klien tugasan ini ialah satu baris.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Sekarang bandingkan entri pelayan untuk klien yang sama. Ia menerangkan apa yang pelayan akan hantar kepada klien, iaitu biasanya alamat terowong klien, bukan subnet peribadi.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Menukar kedua-duanya ialah kesilapan yang paling kerap saya lihat. Meletakkan 10.20.0.0/16 di bawah bahagian peer pelayan menyatakan seluruh subnet berada di belakang klien itu, dan itu tuntutan tapak-ke-tapak, bukan kebenaran. Paket yang tidak sepadan dengan AllowedIPs mana-mana peer digugurkan secara senyap, jadi entri yang salah kelihatan tepat seperti masalah tembok api.

Jika anda mengurus laluan sendiri, tetapkan Table = off di bawah [Interface] dan tambah laluan yang anda mahu. Ketika itu tiada apa ditambah secara automatik, jadi laluan itu tergolong dalam apa yang menaikkan antara muka.

OpenVPN: tolak laluan itu, kemudian pastikan ia mendarat

Pada pelayan biasa perubahannya ialah satu arahan dalam konfigurasi pelayan, di sebelah kumpulan klien.

push "route 10.20.0.0 255.255.0.0"

Klien menambahnya apabila menyambung. Mod kegagalan muncul apabila profil yang sama juga menolak redirect-gateway, atau apabila seseorang sudah menambah route-nopull: yang pertama menjadikan sesi terowong penuh, dan yang kedua membuang setiap laluan yang ditolak termasuk milik anda.

Klien yang memerlukan tingkah laku sempit terhadap pelayan terowong penuh patut mengabaikan hanya bahagian yang tidak dikehendakinya. Dalam OpenVPN 2.4 dan selepasnya, pull-filter wujud khusus untuk itu.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Asingkan keluarga alamat: laluan IPv4 yang ditolak tidak melakukan apa-apa untuk perkhidmatan dalaman yang menyelesaikan ke IPv6, dan perkhidmatan itu gagal melalui terowong sementara yang lain kelihatan baik.

Apabila subnet peribadi bukan pada pelayan VPN tetapi di belakang klien lain, pelayan perlu dimaklumkan. Tambah fail bagi setiap klien melalui client-config-dir yang mengandungi iroute 10.20.0.0 255.255.0.0, serta route yang sepadan supaya klien lain mempelajari laluan itu. Tanpa iroute pelayan tiada sebab menghantar awalan itu melalui terowong tertentu itu.

IPsec: pemilih trafik mesti bersetuju

Dengan IPsec tiada laluan untuk ditolak. Kedua-dua hujung merundingkan alamat mana yang berada di dalam terowong, dan trafik di luar pemilih yang dipersetujui tidak disulitkan dan tidak dihantar melaluinya. Pada klien strongSwan pemilihnya eksplisit.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Jika get laluan dikonfigurasi dengan 0.0.0.0/0 pada kedua-dua belah, penyempitan IKEv2 biasanya mengurangkan SA anak kepada persilangan kedua-dua cadangan, yang merupakan hasil yang dikehendaki. Sesetengah get laluan sebaliknya menolak cadangan yang tidak sepadan dengan pemilih terkonfigurasinya, dan log kemudian menunjukkan SA anak yang gagal dan bukan aduan penghalaan. Apabila itu berlaku, perubahan itu milik get laluan, kerana laluan klien tidak boleh mencipta terowong untuk pemilih yang tidak akan diterima pihak lain.

Pada Windows klien terbina dalam menyembunyikan keputusan yang sama di sebalik dua tetapan. Pemisahan terowong mesti dihidupkan, dan awalan mesti didaftarkan pada profil.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Pendaftaran awalan itulah yang membuatnya bertahan selepas sambung semula, yang tidak dilakukan oleh laluan yang ditambah dengan tangan.

Jauhkan titik akhir dan DNS daripada keputusan

Titik akhir VPN mesti kekal boleh dicapai tanpa terowong, jika tidak terowong runtuh ke dalam dirinya. Apabila hanya 10.20.0.0/16 dihalakan itu automatik, kerana titik akhir ialah alamat awam. Pada profil terowong penuh ia tidak begitu, dan klien memerlukan laluan hos eksplisit ke titik akhir sebelum terowong naik.

DNS ialah keputusan kedua yang tidak diambil oleh penolakan laluan untuk anda. Nama dalaman biasanya diselesaikan melalui penyelesai yang hanya boleh dicapai oleh rangkaian peribadi. Jika pelayan menolak pelayan DNS, setiap nama melaluinya; jika tidak, nama dalaman sama ada gagal atau diselesaikan secara awam kepada sesuatu yang anda tidak maksudkan. DNS berpecah menyimpan satu domain carian pada penyelesai dalaman, tetapi itu bergantung pada sokongan klien, jadi anggap ia sebagai tugasan tersendiri dan bukan kesan sampingan penghalaan.

Sahkan, kemudian but semula dan sahkan sekali lagi

Tiga ujian meliputi persoalan penghalaan. Tanya kernel ke mana alamat jauh akan pergi, ambil sesuatu dari dalam subnet, kemudian sahkan bahawa permintaan awam biasa masih keluar melalui sambungan biasa anda.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

Baris pertama menamakan antara muka. Jika ia menamakan antara muka fizikal anda, laluan itu tidak pernah mendarat. Pada Windows Find-NetRoute -RemoteIPAddress 10.20.5.7 menjawab soalan yang sama, dan ujian terakhir sepatutnya masih menunjukkan alamat biasa anda dan bukan alamat pelayan VPN.

Kemudian but semula. Laluan yang ditambah dengan tangan hilang, manakala laluan daripada profil, daripada konfigurasi yang ditolak atau daripada AllowedIPs kembali. Jika akses sempit berfungsi sebelum mula semula dan gagal selepasnya, kesalahannya terletak pada cara terowong bermula, bukan pada laluan itu sendiri.

Sebelum menganggapnya selesai, sahkan empat perkara: awalan itu datang daripada pemilik rangkaian dan tidak bertindih dengan apa-apa yang setempat, laluan balik wujud atau peraturan penyamaran menggantikannya, mekanisme yang anda konfigurasi ialah yang menguatkuasakan penghalaan pada platform anda, dan ujian yang sama lulus selepas mula semula yang bersih. nota penghantaran strongSwan wajar dibaca jika laluan balik ialah bahagian yang terus gagal.