VLAN klien atau trunk bertag: pilih mode OpenVPN yang tepat

Dua permintaan datang dengan kata-kata yang hampir sama: tempatkan setiap klien VPN di VLAN pilihan, atau bawa trunk VLAN yang sudah ada melewati VPN. Keduanya produk berbeda. Mode bawaan OpenVPN yang sadar VLAN adalah model switch untuk permintaan pertama, dan bukan sinonim transportasi tag transparan. Memilih yang salah menghasilkan desain yang tampak terkonfigurasi dan diam-diam membuang frame yang Anda pedulikan.

Apa yang sebenarnya dibangun mode sadar VLAN

Dengan vlan-tagging diaktifkan pada penerapan TAP khusus server, daemon memodelkan perangkat TAP-nya dan setiap klien yang terhubung sebagai port pada switch internal. Port klien tidak bertag, dan asosiasi VLAN-nya diatur di server melalui konteks vlan-pvid per klien, bukan oleh apa pun yang dikirim klien. Itulah inti modelnya: keanggotaan adalah keputusan di sisi server tentang peer yang terautentikasi. Tidak ada apa pun di profil klien yang perlu tahu VLAN mana yang menjadi miliknya.

Sisi TAP server mendapat kebijakan penerimaan bertag atau tanpa tag sendiri melalui vlan-accept. Penerusan di dalam switch itu hanya terjadi antar VID yang cocok, termasuk saat client-to-client diatur, sehingga dua klien di VLAN berbeda tidak dapat saling menjangkau melalui server meskipun keduanya terhubung ke sana.

Model itu adalah model port akses. Frame yang keluar dari klien tidak bertag, dan asosiasinya dipaksakan oleh server berdasarkan identitas. Meminta laptop menandai trafiknya sendiri berarti meminta desain lain.

Penetapan harus mengikuti identitas klien yang terautentikasi, bukan nilai yang ditawarkan klien tentang dirinya. Penetapan yang dihilangkan juga bukan status karantina: klien mendarat di PVID default, jadi entri ccd yang hilang adalah keputusan kebijakan yang senyap, bukan netral.

Apa yang justru dibutuhkan trunk transparan

Membawa frame yang sudah bertag dari ujung ke ujung dimulai dengan mematikan pemrosesan sadar VLAN. Model switch dan pemeliharaan tag adalah alternatif, dan mengaktifkan keduanya berarti meminta satu fitur mengerjakan tugas yang lain.

Mematikannya hanyalah awal. Bridge di setiap ujung dan port fisik switch harus sepakat tentang VLAN mana yang diizinkan, tag mana yang native, dan bagaimana frame tanpa tag diperlakukan. Memperluas trunk tanpa batas memaparkan jauh lebih banyak domain siaran daripada dua yang ingin Anda hubungkan.

Ukuran frame membutuhkan anggarannya sendiri. Frame Ethernet bertag ditambah enkapsulasi lebih besar daripada angka muatan yang orang salin dari panduan, dan MTU yang cocok untuk tunnel terutek tidak menjadi bukti bahwa jalur trunk berfungsi.

Tiga syarat yang menentukan jawabannya

Pertama, apakah platform klien mendukung TAP sama sekali? Android dan iOS tidak, dan dukungan macOS terbatas, sehingga armada pengguna seluler mencoret kedua desain TAP, tak peduli bagaimana VLAN ditata. Sesi TUN terutek membawa paket IP, bukan frame Ethernet, dan tidak ada konfigurasi VLAN di sisi server yang mengubahnya. Periksa armada sebelum merancang topologi, karena syarat inilah yang tidak dapat diakali. Ini juga syarat yang paling sering baru ditemukan setelah pekerjaan switch selesai.

Kedua, siapa yang menetapkan VLAN? Jika jawabannya «server, berdasarkan siapa yang terautentikasi», model switch cocok. Jika jawabannya «infrastruktur switch yang ada, dengan tag yang sudah ada», Anda memerlukan desain trunk.

Ketiga, seberapa besar jaringan yang harus dapat dijangkau? Model switch menjaga setiap klien dalam satu VLAN secara konstruksi. Desain trunk adalah bridge, dan bridge yang salah konfigurasi menyatukan domain siaran yang seharusnya tetap terpisah.

Menguji pilihan yang Anda buat

Hubungkan satu klien yang seharusnya berada di VLAN yang diizinkan dan satu yang seharusnya tidak, lalu uji dari ujung sebenarnya, bukan dari server itu sendiri. Keterjangkauan dari sisi server membuktikan bridge atau switch ada; itu tidak membuktikan VLAN mana yang ditempati klien.

ip -d link show tap0
bridge vlan show

Di server, perintah kedua menampilkan keanggotaan VLAN setiap port bridge, termasuk apakah port tersebut bertag. Bandingkan dengan penetapan yang Anda maksud sebelum men-debug apa pun di atas lapisan dua.

Catat desain mana dari keduanya yang dipakai penerapan. Catatan yang berbunyi «sadar VLAN» ambigu, dan insinyur berikutnya akan menganggap yang pertama ia pelajari. Referensi VLAN OpenVPNmendefinisikan perilaku switch dan konteks per klien, dan itu jalur terpendek untuk memastikan model mana yang Anda jalankan.