Apakah dua situs perlu VLAN ID yang sama untuk VPN situs?

Nomor VLAN yang sama di dua kantor terasa seolah harus membantu terowongan antar-situs, dan itu tidak mengubah apa pun tentang yang dibawa terowongan. VLAN ID menandai domain siaran Ethernet di dalam satu gedung; terowongan meneruskan paket IP antar gateway. Dua situs dapat memakai penomoran VLAN yang sama sekali berbeda dan tetap merutekan ke satu sama lain, dan dua situs dapat memakai penomoran VLAN yang identik dan tetap tidak dapat saling menjangkau. Variabel yang menentukan keterjangkauan adalah rencana alamat.

Mitos: VLAN ID yang sama di kedua ujung

Keyakinan itu datang dari tempat yang masuk akal. Di dalam satu gedung, dua port di VLAN yang sama dapat berbicara dan dua port di VLAN berbeda tidak, jadi nomor VLAN tampak seperti hal yang memberikan konektivitas. Di seberang terowongan yang dirutekan tidak ada segmen Ethernet bersama yang dapat dijelaskan tag, dan gateway tidak pernah bertukar label VLAN.

Yang dibutuhkan terowongan adalah sepasang cakupan alamat yang tidak tumpang tindih dan kebijakan yang mengizinkan lalu lintas di antaranya. Ubah VLAN di kantor mana pun dan terowongan tetap berfungsi, karena tidak ada apa pun dalam konfigurasi terowongan yang merujuknya. Itulah uji yang menyelesaikan perdebatan: nomori ulang VLAN, biarkan alamatnya, dan lihat apakah terowongan tetap hidup.

Uji sebaliknya sama instruktifnya. Beri kedua kantor subnet yang sama dan tidak ada jumlah nomor VLAN yang sama yang akan membuat alamat menjadi tidak ambigu.

Apa yang sebenarnya dibawa terowongan

IPsec melindungi paket IP menurut kebijakan yang dinyatakan dalam alamat, protokol, dan port. Arsitektur IPsec menjelaskan selektor tersebut pada lapisan IP, yang beberapa lapisan di atas apa pun yang dijelaskan tag sakelar. Saat paket masuk ke terowongan, paket itu sudah meninggalkan VLAN; tag telah dikonsumsi sakelar lokal.

Desain berbasis kebijakan dan berbasis rute berbeda dalam cara memilih terowongan, bukan dalam apa yang dapat dibawanya. Rekan berbasis kebijakan mencocokkan selektor lalu lintas dan mengirim paket yang cocok ke terowongan. Rekan berbasis rute merutekan lalu lintas di antarmuka terowongan dan membiarkan tabel perutean memutuskan. Keduanya masih menegosiasikan cakupan perlindungan, jadi rute yang menunjuk ke terowongan tidak memperluas apa yang disepakati para rekan untuk dilindungi.

Perbedaan itu menjelaskan kegagalan separuh yang umum: rute ada, paket masuk ke terowongan, dan sisi jauh membuangnya karena selektor yang dinegosiasikan tidak pernah menyertakan prefiks itu. Membaca kebijakan yang terpasang menunjukkan cakupan mana yang benar-benar berlaku.

ip xfrm policy
ip route show
swanctl --list-sas

Tumpang tindih yang benar-benar merusak

Dua kantor dengan subnet berbeda merutekan dengan bersih melalui terowongan, dan nomor VLAN mereka tidak relevan. Dua kantor dengan subnet yang sama tidak, karena permintaan untuk alamat tertentu punya dua makna yang mungkin dan tabel perutean hanya dapat memilih satu. Menomori ulang satu situs adalah perbaikan yang bersih, dan biasanya lebih murah daripada alternatifnya setelah perubahan DNS dan firewall dihitung.

Saat penomoran ulang tidak mungkin, desain penerjemahan yang disengaja dapat menyajikan tampilan alamat yang berbeda ke tiap sisi. Itu berarti pemetaan satu-ke-satu, selektor yang cocok, entri DNS yang mencerminkan tampilan terjemahan, dan perutean balik yang bertahan dari penulisan ulang. Ini desain yang didukung dengan biaya operasional nyata, dan bukan itu yang dilakukan mengubah VLAN ID.

Nomor VLAN yang sama di kedua ujung kadang kebetulan dari templat bersama, dan memperlakukan kebetulan itu sebagai penyebab terowongan yang berfungsi mengarah ke perubahan yang salah ketika sesuatu rusak kemudian.

Satu tugas per lapisan, tertulis

Sakelar lokal memutuskan port mana yang berbagi domain siaran, dan penomoran VLAN-nya adalah pembukuan lokal yang tidak perlu diketahui situs lain. Gateway mengautentikasi rekan dan menegakkan cakupan perlindungan yang dinegosiasikan. Tabel perutean memutuskan ke mana paket yang didekripsi pergi berikutnya, dan kebijakan akses memutuskan apakah paket itu seharusnya diizinkan sama sekali.

Menjaga tugas-tugas itu tetap terpisah adalah yang membuat perubahan aman. Penomoran ulang VLAN di satu kantor menyentuh sakelar lokal, cakupan DHCP, dan mungkin zona firewall, dan tidak menyentuh terowongan. Perubahan prefiks menyentuh selektor terowongan, rute di kedua sisi, dan kebijakan akses, dan tidak menyentuh tag sakelar.

Rute balik, DNS privat, dan persyaratan identitas aplikasi lagi-lagi tugas terpisah, dan tidak satu pun datang dengan menyalin nomor VLAN dari situs lain. Dokumen desain yang mencantumkan prefiks terjangkau dan layanan yang diizinkan bertahan dari penggantian sakelar; yang mencantumkan nomor VLAN tidak.

Konfirmasikan gambaran lokal dengan perkakas bridge sebelum menganggap tag mencapai terowongan.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Saat perluasan layer-2 adalah kebutuhan sebenarnya

Sebagian desain benar-benar membutuhkan perilaku Ethernet antar situs: aplikasi lama yang bergantung pada penemuan siaran, migrasi yang harus mempertahankan alamat saat mesin berpindah, atau protokol yang menyematkan asumsi layer-2. Kasus seperti itu memerlukan overlay atau layanan jembatan yang membawa frame, dan kemudian keanggotaan VLAN, pencegahan loop, dan penanganan kegagalan menjadi urusan ujung ke ujung.

Itu domain kegagalan yang jauh lebih besar, dan itu seharusnya menjadi pilihan yang disengaja, bukan hasil kebetulan dari upaya membuat berbagi berkas berfungsi. Server berkas, basis data, atau aplikasi web biasa membutuhkan jalur IP yang berwenang, dan akan lebih bahagia tanpa domain siaran yang membentang di bawahnya.

Tulis kontrak VPN sebagai prefiks yang dapat dijangkau plus layanan yang diizinkan, dan catat label VLAN hanya di tempat operasi lokal membutuhkannya. Setiap kantor kemudian dapat menomori ulang sakelarnya sendiri tanpa mengubah setiap perubahan menjadi desain ulang terowongan.