Cara mengirim hanya satu subnet privat melalui VPN

Satu subnet privat melalui terowongan dan semua yang lain lewat jalur normal Anda adalah permintaan kecil dengan banyak cara untuk salah. Yang menentukan hasil bukan kotak centang bernama split tunneling, melainkan di mana keputusan ditegakkan: tabel rute milik klien sendiri, rute yang didorong server, atau kebijakan yang dinegosiasikan kedua ujung. Pilih lapisan yang salah dan Anda mendapat terowongan penuh yang tidak pernah Anda inginkan, atau rute menuju terowongan yang ditolak sisi lain. Saya memakai uji tiga syarat sebelum membuka konfigurasi apa pun, lalu memilih salah satu mekanisme di bawah.

Tiga syarat yang menentukan desain

Pertama, Anda perlu prefiks dan mask yang tepat dari pemilik jaringan. Jaringan 10.x bukan prefiks; 10.20.0.0/16 adalah prefiks. Pastikan tidak tumpang tindih dengan LAN rumah, jembatan Docker, atau VPN lain yang Anda jalankan, karena tumpang tindih membuat rute ambigu dan kernel memilih entri yang tidak Anda maksud.

Kedua, siapa yang menjawab lalu lintas balasan. Merutekan paket ke terowongan hanya membawanya ke server VPN. Jika subnet berada di belakang router lain yang tidak punya rute balik ke kumpulan klien Anda, server harus melakukan masquerade, atau router itu harus mempelajari kumpulan Anda. Tidak ada rute di sisi klien yang memperbaiki jalur balik yang hilang.

Ketiga, titik penegakannya. Sebagian klien memasang rute dan sistem operasi mengerjakan sisanya. Yang lain menegosiasikan kebijakan, dan kebijakan yang tidak diterima gateway tidak menghasilkan terowongan sama sekali: paket dibuang tanpa kesalahan yang jelas. Tentukan mana dari keduanya milik Anda sebelum menulis apa pun.

WireGuard: AllowedIPs adalah tabel rute

Di klien, AllowedIPs mendaftar tujuan yang boleh masuk terowongan, dan wg-quick mengubah setiap entri menjadi rute biasa. Jadi separuh klien dari tugas ini satu baris.

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

Sekarang bandingkan entri server untuk klien yang sama. Entri itu menjelaskan apa yang akan dikirim server ke klien, yang biasanya alamat terowongan klien, bukan subnet privat.

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

Menukar keduanya adalah kesalahan yang paling sering saya lihat. Menaruh 10.20.0.0/16 di bagian peer server menyatakan seluruh subnet berada di belakang klien itu, dan itu klaim situs-ke-situs, bukan izin. Paket yang tidak cocok dengan AllowedIPs peer mana pun dibuang diam-diam, sehingga entri yang salah tampak persis seperti masalah firewall.

Jika Anda mengelola rute sendiri, setel Table = off di bawah [Interface] dan tambahkan rute yang Anda inginkan. Saat itu tidak ada yang ditambahkan otomatis, jadi rute itu berada di dalam apa pun yang menaikkan antarmuka.

OpenVPN: dorong rutenya, lalu pastikan rute itu mendarat

Pada server biasa perubahannya satu direktif di konfigurasi server, di samping kumpulan klien.

push "route 10.20.0.0 255.255.0.0"

Klien menambahkannya saat terhubung. Mode kegagalan muncul ketika profil yang sama juga mendorong redirect-gateway, atau ketika seseorang sudah menambahkan route-nopull: yang pertama mengubah sesi menjadi terowongan penuh, dan yang kedua membuang setiap rute yang didorong termasuk milik Anda.

Klien yang butuh perilaku sempit terhadap server terowongan penuh sebaiknya mengabaikan hanya bagian yang tidak diinginkannya. Di OpenVPN 2.4 dan setelahnya, pull-filter ada persis untuk itu.

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

Pisahkan keluarga alamat: rute IPv4 yang didorong tidak berguna bagi layanan internal yang resolve ke IPv6, dan layanan itu gagal lewat terowongan sementara yang lain tampak baik-baik saja.

Ketika subnet privat tidak berada di server VPN melainkan di belakang klien lain, server harus diberi tahu. Tambahkan berkas per klien melalui client-config-dir yang berisi iroute 10.20.0.0 255.255.0.0, plus route yang cocok agar klien lain mempelajari jalurnya. Tanpa iroute server tidak punya alasan mengirim prefiks itu melalui terowongan tertentu itu.

IPsec: selektor lalu lintas harus sepakat

Dengan IPsec tidak ada rute untuk didorong. Kedua ujung menegosiasikan alamat mana yang berada di dalam terowongan, dan lalu lintas di luar selektor yang disepakati tidak dienkripsi dan tidak dikirim melaluinya. Pada klien strongSwan selektornya eksplisit.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Jika gateway dikonfigurasi dengan 0.0.0.0/0 di kedua sisi, penyempitan IKEv2 biasanya mereduksi SA anak ke irisan kedua proposal, yang memang hasil yang diinginkan. Sebagian gateway justru menolak proposal yang tidak cocok dengan selektor terkonfigurasinya, dan log lalu menampilkan SA anak yang gagal, bukan keluhan perutean. Bila itu terjadi, perubahannya ada di gateway, karena rute di klien tidak dapat membuat terowongan untuk selektor yang tidak akan diterima sisi lain.

Di Windows klien bawaan menyembunyikan keputusan yang sama di balik dua pengaturan. Pemisahan terowongan harus aktif, dan prefiks harus didaftarkan pada profil.

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

Pendaftaran prefiks itulah yang membuatnya bertahan setelah sambung ulang, yang tidak dilakukan rute yang ditambahkan dengan tangan.

Jauhkan titik akhir dan DNS dari keputusan

Titik akhir VPN harus tetap terjangkau tanpa terowongan, jika tidak terowongan runtuh ke dalam dirinya sendiri. Ketika hanya 10.20.0.0/16 yang dirutekan itu otomatis, karena titik akhir adalah alamat publik. Pada profil terowongan penuh tidak demikian, dan klien memerlukan rute host eksplisit ke titik akhir sebelum terowongan naik.

DNS adalah keputusan kedua yang tidak diambil dorongan rute untuk Anda. Nama internal biasanya resolve melalui resolver yang hanya dapat dijangkau jaringan privat. Jika server mendorong server DNS, setiap nama melewatinya; jika tidak, nama internal gagal atau resolve secara publik ke sesuatu yang tidak Anda maksud. DNS terpisah menyimpan satu domain pencarian di resolver internal, tetapi itu bergantung pada dukungan klien, jadi perlakukan sebagai tugas tersendiri dan bukan efek samping perutean.

Verifikasi, lalu reboot dan verifikasi lagi

Tiga pemeriksaan mencakup pertanyaan perutean. Tanyakan ke kernel ke mana alamat jauh akan pergi, ambil sesuatu dari dalam subnet, lalu pastikan permintaan publik biasa masih keluar lewat koneksi normal Anda.

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

Baris pertama menyebut sebuah antarmuka. Jika yang disebut antarmuka fisik Anda, rutenya tidak pernah mendarat. Di Windows Find-NetRoute -RemoteIPAddress 10.20.5.7 menjawab pertanyaan yang sama, dan pemeriksaan terakhir seharusnya tetap menampilkan alamat biasa Anda, bukan alamat server VPN.

Lalu reboot. Rute yang ditambahkan dengan tangan hilang, sementara rute dari profil, dari konfigurasi yang didorong, atau dari AllowedIPs kembali. Jika akses sempit bekerja sebelum restart dan gagal sesudahnya, kesalahannya ada pada cara terowongan dimulai, bukan pada rutenya sendiri.

Sebelum menyebutnya selesai, pastikan empat hal: prefiks berasal dari pemilik jaringan dan tidak tumpang tindih dengan apa pun yang lokal, jalur balik ada atau aturan masquerade menggantikannya, mekanisme yang Anda konfigurasi adalah yang menegakkan perutean di platform Anda, dan pemeriksaan yang sama lolos setelah reboot bersih. Catatan penerusan strongSwan layak dibaca jika jalur balik adalah bagian yang terus gagal.