Mengapa VPN tunnel penuh menyembunyikan VLAN lokal yang dirutekan

Sakelar “allow local network” di klien VPN terdengar seolah mencakup semua yang ada di gedung. Dalam praktiknya klien biasanya hanya menambahkan beberapa pengecualian alamat privat ke rute default tunnel lalu berhenti di situ. VLAN penyimpanan Anda tetap terjangkau hanya jika rute untuk prefiks tertentu itu bertahan saat tunnel masuk, dan pada banyak klien hal itu tidak terjadi.

Ini soal perutean, bukan pengaturan VPN, yang merupakan kabar baik: ada jawaban konkretnya.

Apa yang sebenarnya dicakup allow-local-network

Klien menerapkan opsi itu secara berbeda. Sebagian menambahkan rute untuk subnet tempat mesin tersambung, sebagian menambahkan rentang RFC 1918, dan beberapa hanya mengecualikan gateway default. Tidak satu pun dari mereka tahu bahwa router kantor Anda juga melayani VLAN penyimpanan, segmen lab, atau subnet printer, karena prefiks itu tidak ada di kabel yang bisa dilihat klien. Bacalah dokumentasi klien itu sendiri untuk perilaku yang tepat alih-alih menganggap label tersebut menggambarkan topologi Anda.

Perbedaannya paling penting dalam desain tunnel penuh, tempat klien sengaja mengganti rute default agar semua lalu lintas melewati VPN. Itulah inti seluruh desain, dan itulah yang membuat jaringan lokal yang dirutekan menghilang. Jaringan itu tidak pernah dicakup rute sendiri; mereka menumpang pada rute default yang baru saja diganti. Klien tidak bisa merutekan apa yang tidak diketahuinya ada, dan ia hanya mempelajari prefiks yang terpasang pada antarmukanya sendiri. Sisanya harus dijelaskan oleh seseorang yang tahu topologinya.

Rute terhubung berhenti di router pertama

Stasiun kerja di 192.168.10.20/24 dengan gateway 192.168.10.1 otomatis mendapat rute terhubung untuk 192.168.10.0/24. VLAN penyimpanan di 192.168.20.0/24 adalah prefiks berbeda, hanya terjangkau melalui gateway itu, dan stasiun kerja tidak punya rute untuknya selain rute default. Sebelum tunnel naik, rute default biasa kebetulan mengirim lalu lintas penyimpanan ke 192.168.10.1 dan semuanya berjalan.

Ketika VPN memasang rute default tunnel penuh, paket menuju 192.168.20.1 mengikuti rute default baru masuk ke tunnel. Gateway jauh tidak tahu di mana prefiks itu berada, jadi ia membuangnya atau meneruskannya ke tempat yang tidak berguna. Tidak ada yang salah konfigurasi di VLAN penyimpanan; jalurnya dipinjam, dan pinjaman itu ditagih kembali.

Godaannya adalah meraih pengecualian lebar seperti sepasang rute /1 atau rute default kedua. Tahanlah. Semakin sempit pengecualiannya, semakin mudah dijelaskan, diaudit, dan dihapus saat jaringan berubah.

Taruh pengecualian di tabel yang menang

Dalam satu tabel perutean, /24 mengalahkan /0 atau /1 melalui pencocokan prefiks terpanjang, jadi rute spesifik ke VLAN penyimpanan melalui gateway lokal sudah cukup, asalkan tabel itu benar-benar diperiksa. Di Linux bentuk biasanya singkat:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

Perutean berbasis kebijakan mempersulit jaminan itu. Aturan yang lebih awal bisa mengirim lalu lintas ke tabel yang rute default-nya sendiri menunjuk ke dalam tunnel, dan tabel utama yang memuat /24 Anda kemudian tidak pernah tercapai. Periksa aturannya sebelum menganggap rute itu berwenang, karena entri yang tampak benar di tabel yang salah menjelaskan kegagalan yang tampak seperti rute rusak.

Lalu buat entri itu persisten melalui mekanisme yang didukung klien atau pengelola jaringan yang memiliki antarmuka tersebut. Rute yang diketik di prompt hilang pada penyambungan ulang berikutnya, dan rute yang terikat pada satu gateway Wi-Fi tidak portabel ke jaringan berikutnya yang dikunjungi laptop.

Nama dan kebijakan tidak mengikuti rute

Memperbaiki rute memulihkan paket, bukan nama. Jika perangkat lokal diselesaikan melalui resolver yang dipaksakan dan tidak tahu apa pun tentangnya, mount tetap gagal meskipun alamatnya terjangkau. Nama lokal memerlukan pengaturan DNS lokal atau terpisah, dan itu keputusan terpisah dari pengecualian rute.

Kebijakan juga terpisah lagi. Filter akses lokal klien VPN dapat dengan sengaja melarang lalu lintas ke rentang privat, dan rute tidak mengesampingkan aturan itu. Di jaringan yang tidak tepercaya, alamat privat juga bukan bukti bahwa tujuannya adalah server penyimpanan Anda, jadi pengecualiannya harus sespesifik rute itu sendiri.

Kontrak yang bisa Anda serahkan

Desain akhirnya harus terbaca sebagai daftar pendek: lalu lintas internet umum mengikuti tunnel, dan prefiks lokal bernama ini mempertahankan jalurnya melalui router lokal. Tuliskan prefiks, hop berikutnya, dan sufiks DNS yang menyertainya, dan jaga daftarnya cukup pendek agar orang lain dapat memverifikasinya tanpa membaca tabel perutean.

Perhatikan tumpang tindih antara rentang lokal dan jarak jauh. VLAN penyimpanan yang berbagi prefiks dengan sesuatu di balik VPN akan diselesaikan ke rute yang lebih spesifik, dan perilaku yang dihasilkan membingungkan dengan cara yang tampak tidak menentu. Menomori ulang satu sisi biasanya lebih murah daripada mendebug ambiguitas selamanya.

Uji kontraknya dua kali: sekali dengan tunnel menyala dan sekali dengan tunnel mati. Jika jalur lokal hanya berfungsi di salah satu keadaan itu, pengecualiannya belum menjadi kontrak.