Satu Perangkat Lewat VPN Router Butuh Tiga Aturan, Bukan Tombol

Di VPN router tidak ada tombol per perangkat; tombol yang Anda cari itu sebenarnya jalan pintas yang menulis aturan policy routing atas nama Anda. Begitu satu laptop, satu rentang port, satu daftar alamat, atau satu segmen LAN harus memakai tunnel sementara sisanya tetap di WAN, Anda sedang membangun policy route, bukan mengaktifkan fitur. Pekerjaan ini punya tiga bagian yang bergerak, dan masing-masing gagal dengan caranya sendiri: tabel bertanda tanpa rute terlihat seperti diam, mark yang dipasang di chain keliru terlihat seperti tidak ada yang terjadi, dan aturan NAT yang hilang terlihat seperti tunnel yang tersambung tetapi tidak mengangkut apa pun. Dua bagian lagi juga hilang karena tidak pernah muncul di aturan mangle, yaitu DNS dan IPv6.

Mitos: tunnel itu pengaturan klien

Klien VPN di sisi router melakukan satu hal kasar dengan baik: ia menaruh 0.0.0.0/0 di tabel routing utama dan mengarahkannya ke tunnel. WireGuard menurunkan itu dari AllowedIPs, OpenVPN dari redirect-gateway yang dipush, dan keduanya mengubah jalur setiap host di belakang router. Mempersempit AllowedIPs atau menambah route-nopull mengubah apa yang dipasang klien. Itu tidak mengubah siapa yang kena pemasangan tersebut, karena klien tidak pernah melihat perangkat. Ia hanya melihat paket.

Pemilihan berdasarkan sumber atau tujuan adalah keputusan routing, jadi tempatnya di lapisan policy router: aturan mangle plus tabel kedua di RouterOS, MARK plus ip rule di OpenWrt atau DD-WRT, atau aturan firewall yang gateway-nya tunnel di pfSense. Resep klien WireGuard dari Netgate adalah yang perlu dibaca sebelum menebak, karena di platform itu gateway aturan, penetapan antarmuka, dan entri NAT keluar harus semuanya sepakat sebelum satu klien pun memakai tunnel.

Separuh kedua mitos itu adalah router kedua. Membeli kotak lain, atau memindahkan perangkat ke SSID tamu, sering berhasil, dan alasannya bukan perangkat kerasnya: itu menaruh perangkat di subnet sendiri, yang memberi Anda pemilih sumber yang sudah dipahami firmware. Kalau Anda bisa mendefinisikan segmen itu di router yang Anda miliki, kotak tambahan hanya menyelesaikan masalah yang tidak Anda punya.

Bagian satu: tunnel yang bukan rute default

Di RouterOS, tambahkan klien tanpa rute default dan beri tunnel tabelnya sendiri. Rute pertama adalah default bertanda; yang kedua adalah separuh kegagalan.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

Rute unreachable itulah sebabnya tabel bertanda mengalahkan daftar pengecualian di tabel utama. Saat tunnel putus, paket bertanda langsung mendapat unreachable alih-alih diam-diam kembali ke WAN, jadi kegagalannya muncul di pesan galat aplikasi, bukan di halaman geolokasi yang Anda periksa sejam kemudian.

RouterOS 7 memisahkan apa yang 6.x satukan: Anda mendeklarasikan tabel dengan /routing table add name=vpn fib, lalu merujuknya dengan nama di rute dan di aturan mangle. Cuplikan 6.x yang menuliskan routing-mark tanpa mendefinisikan tabel tetap termuat bersih dan tidak cocok dengan apa pun. Klasik lainnya adalah dua separuh 0.0.0.0/1, atau dua default pada jarak sama dalam satu tabel: kernel memilih satu, dan perilakunya bisa berubah setelah reboot.

Bagian dua: tandai sebelum pencarian rute

Pemilih menentukan paket mana yang masuk tabel itu. RouterOS biasanya mulai dengan daftar alamat untuk kebijakan tujuan, atau alamat sumber untuk kebijakan perangkat:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Firmware Linux melakukan hal yang sama dengan mark netfilter dan aturan yang mengarahkan paket bertanda ke tabel yang Anda isi:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

Chain bukan pilihan gaya. Saat paket mencapai FORWARD, pencarian rute sudah terjadi, jadi MARK atau DROP di situ hanya bisa menulis ulang atau membuang. Mark harus mendarat di PREROUTING untuk lalu lintas yang diteruskan dan di OUTPUT untuk lalu lintas yang berasal dari router, tempat DNS router, NTP, dan pemeriksaan pembaruan berada. Jalur output itulah alasan biasa mengapa penyiapan yang sepenuhnya lewat tunnel masih menjawab dari resolver ISP dalam uji kebocoran.

Kebijakan perangkat butuh pencocokan yang tidak bergeser. Reservasikan alamat di DHCP, atau cocokkan antarmuka untuk segmen khusus; alamat yang kemudian pindah ke perangkat lain diam-diam menerapkan tunnel ke klien yang salah. Bridge per-SSID dengan subnet sendiri adalah versi yang lebih tahan lama dari gagasan yang sama, dan itu juga memberi aturan IPv6 tempat tinggal.

Bagian tiga: NAT, DNS, dan pengecualian LAN

Lalu lintas yang keluar lewat tunnel butuh alamat sumber yang akan dijawab sisi jauh. Batasi penerjemahan ke antarmuka tunnel: out-interface=VPN_NAME di RouterOS, -o tun0 di Linux, entri NAT keluar yang cocok di pfSense. Aturan masquerade tanpa pembatasan itu menulis ulang lalu lintas yang seharusnya Anda biarkan, dan gejalanya adalah perangkat yang tidak lewat tunnel kehilangan alamat publiknya.

Pengecualian LAN menyebabkan lebih banyak utas dukungan daripada tunnel itu sendiri. Kalau tabel bertanda hanya berisi rute default, tujuan printer atau NAS dari perangkat terpilih cocok dengan default itu dan hilang ke dalam tunnel. Tambahkan rute LAN ke tabel yang sama, atau kecualikan subnet lokal di pemilih; keduanya berhasil, dan pengecualian lebih mudah dijaga benar saat Anda menambah VLAN nanti.

DNS menempuh jalur terpisah. Kueri yang diteruskan router berasal dari router dan mengikuti OUTPUT, bukan mark yang diteruskan, jadi laptop yang sepenuhnya lewat tunnel masih bisa menyelesaikan nama lewat ISP. Arahkan klien ke resolver yang bisa dijangkau lewat tunnel, atau tandai lalu lintas port-53 milik router sendiri, lalu periksa alamat hasil resolusi alih-alih menganggap jawabannya ikut bersama permintaan web.

Saat aturan cocok tetapi aplikasi tetap memakai WAN

Daftar tujuan cepat menua. Sebuah nama resolve ke alamat yang tidak ada di daftar, jadi permintaan lewat WAN padahal setiap uji terhadap alamat yang terdaftar berhasil. Segarkan daftar dari resolver yang sama dengan yang dipakai klien, dan utamakan pemilih berbasis sumber kalau Anda memang ingin semua lalu lintas dari satu perangkat.

IPv6 adalah jalan pintas yang senyap. Perangkat punya keluarga alamat kedua dengan rute default dan set aturannya sendiri, dan hanya mencocokkan alamat IPv4 berarti separuh kebijakan. Terapkan pemilih yang sama ke ip6tables atau padanan nftables, atau matikan IPv6 di segmen itu dengan sengaja, bukan tanpa sengaja.

Koneksi yang sudah terjalin juga penting. Entri conntrack yang dibuat sebelum perubahan terus mengikuti jalur lama sampai kedaluwarsa, jadi peramban yang tetap terbuka selama penyuntingan terlihat persis seperti aturan yang tidak pernah berlaku. Buka koneksi baru, atau bersihkan state, sebelum Anda menilai kebijakannya.

Verifikasi dengan dua perangkat dan satu reboot

Uji perangkat yang seharusnya lewat tunnel dan perangkat yang seharusnya tidak, lalu bandingkan hop kedua, bukan angka kecepatan. Traceroute dari masing-masing menunjukkan gateway tunnel atau gateway ISP di hop dua; kalau keduanya sama, mark atau tabelnya tidak melakukan apa yang dikatakan aturan. Pakai koneksi baru untuk uji itu.

Lalu reboot. Urutan startup adalah tempat kebijakan yang bekerja menjadi rusak, karena klien harus hidup sebelum rute unreachable dipasang, dan snapshot tersimpan yang memulihkan set aturan lama akan menimpa tabel Anda. Periksa bahwa setiap aturan ada di konfigurasi tersimpan dan bahwa default bertanda ada setelah boot, bukan hanya setelah Anda mengetiknya.

Kalau ada yang gagal, lepaskan mark dulu dan lihat apakah lalu lintas normal kembali, baru lepas tabelnya. Urutan itu memberi tahu apakah Anda mengejar masalah routing atau masalah firewall, dan rumah tangga tetap punya printer yang bekerja sementara Anda menyelesaikannya.