İki saha bir saha VPN'i için aynı VLAN ID'lere ihtiyaç duyar mı?

İki ofiste aynı VLAN numaraları sahalar arası bir tünele yardımcı olmalıymış gibi görünür ve tünelin taşıdığı şeyi hiç değiştirmez. Bir VLAN ID, tek bir bina içindeki bir Ethernet yayın alanını etiketler; tünel, IP paketlerini ağ geçitleri arasında iletir. İki saha tamamen farklı VLAN numaralandırması kullanıp yine de birbirine yönlendirebilir ve iki saha aynı VLAN numaralandırmasını kullanıp yine de birbirine ulaşamayabilir. Erişilebilirliği belirleyen değişken adres planıdır.

Mit: iki uçta aynı VLAN ID'ler

İnanç makul bir yerden gelir. Tek bir bina içinde aynı VLAN'daki iki port birbiriyle konuşabilir ve farklı VLAN'lardaki iki port konuşamaz, bu yüzden VLAN numarası bağlantı veren şey gibi görünür. Yönlendirilmiş bir tünelin ötesinde etiketin tanımlayabileceği ortak bir Ethernet segmenti yoktur ve ağ geçitleri hiçbir zaman VLAN etiketlerini değiştirmez.

Tünelin ihtiyacı, birbiriyle çakışmayan iki adres kapsamı ve aralarındaki trafiğe izin veren bir politikadır. Herhangi bir ofiste VLAN'ı değiştirin, tünel çalışmaya devam eder, çünkü tünel yapılandırmasında hiçbir şey ona atıfta bulunmuyordu. Tartışmayı bitiren test budur: VLAN'ı yeniden numaralandırın, adresleri olduğu gibi bırakın ve tünelin ayakta kalıp kalmadığına bakın.

Ters test de aynı derecede öğreticidir. İki ofise aynı alt ağı verin, aynı VLAN numaralarının hiçbir miktarı bir adresi belirsizlikten kurtarmaz.

Tünel gerçekte ne taşır

IPsec, IP paketlerini adresler, protokoller ve portlarla ifade edilen bir politikaya göre korur. IPsec mimarisi bu seçicileri, anahtar etiketinin tanımladığı her şeyden birkaç katman yukarıda olan IP katmanında tanımlar. Bir paket tünele girdiğinde VLAN'ı çoktan terk etmiştir; etiket yerel anahtar tarafından tüketilmiştir.

Politika tabanlı ve rota tabanlı tasarımlar tüneli seçme biçimlerinde farklıdır, taşıyabildikleri şeyde değil. Politika tabanlı eş, trafik seçicilerini eşleştirir ve eşleşen paketleri tünele gönderir. Rota tabanlı eş, trafiği bir tünel arayüzünde yönlendirir ve kararı yönlendirme tablosuna bırakır. İkisi de hâlâ bir koruma kapsamı üzerinde anlaşır, bu nedenle tünele işaret eden bir rota, eşlerin korumayı kabul ettiği kapsamı genişletmez.

Bu ayrım yaygın bir yarım başarısızlığı açıklar: rota vardır, paketler tünele girer ve uzak taraf onları düşürür çünkü anlaşılan seçiciler o öneki hiç içermemiştir. Kurulu politikaları okumak hangi kapsamın gerçekten yürürlüğe girdiğini gösterir.

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

Gerçekten bozan çakışma

Farklı alt ağlara sahip iki ofis bir tünelden temiz biçimde yönlendirilir ve VLAN numaraları önemsizdir. Aynı alt ağa sahip iki ofis yönlendirilemez, çünkü belirli bir adrese yönelik bir isteğin iki olası anlamı vardır ve yönlendirme tablosu yalnızca birini seçebilir. Bir sahayı yeniden numaralandırmak temiz çözümdür ve DNS ile güvenlik duvarı değişiklikleri hesaba katıldığında genellikle alternatiflerden daha ucuzdur.

Yeniden numaralandırma imkânsız olduğunda, kasıtlı bir çeviri tasarımı her tarafa farklı adres görünümleri sunabilir. Bu, bire bir eşleme, eşleşen seçiciler, çevrilmiş görünümü yansıtan DNS kayıtları ve yeniden yazmadan sağ çıkan dönüş yönlendirmesi anlamına gelir. Gerçek işletme maliyeti olan desteklenen bir tasarımdır ve bir VLAN ID'yi değiştirmenin yaptığı şey bu değildir.

İki uçta aynı VLAN numaraları bazen ortak bir şablonun tesadüfüdür ve bu tesadüfü çalışan bir tünelin nedeni saymak, daha sonra bir şey bozulduğunda yanlış değişikliğe yol açar.

Her katman için bir iş, yazılı olarak

Yerel anahtar hangi portların bir yayın alanını paylaştığına karar verir ve VLAN numaralandırması başka bir sahanın bilmesi gerekmeyen yerel bir muhasebedir. Ağ geçidi eşi kimlik doğrular ve anlaşılan koruma kapsamını uygular. Yönlendirme tablosu şifresi çözülmüş bir paketin sonra nereye gideceğine, erişim politikası ise o pakete baştan izin verilmesi gerekip gerekmediğine karar verir.

Bu işleri ayrı tutmak değişiklikleri güvenli kılan şeydir. Bir ofiste VLAN'ı yeniden numaralandırmak yerel anahtara, DHCP kapsamına ve belki bir güvenlik duvarı bölgesine dokunur, tünele dokunmaz. Önek değişikliği tünel seçicilerine, her iki taraftaki rotalara ve erişim politikasına dokunur, anahtar etiketlerine dokunmaz.

Dönüş rotaları, özel DNS ve uygulama kimliği gereksinimleri yine ayrı işlerdir ve hiçbiri diğer sahadan bir VLAN numarası kopyalayarak gelmez. Erişilebilir önekleri ve izin verilen hizmetleri listeleyen bir tasarım belgesi anahtar değişiminden sağ çıkar; VLAN numaralarını listeleyen ise çıkmaz.

Bir etiketin tünele ulaştığını varsaymadan önce yerel görüntüyü köprü araçlarıyla doğrulayın.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

layer-2 genişletmesi gerçek gereksinim olduğunda

Bazı tasarımlar gerçekten sahalar arasında Ethernet davranışına ihtiyaç duyar: yayın keşfine dayanan eski bir uygulama, bir makine taşınırken adresi koruması gereken bir geçiş veya layer-2 varsayımlarını içeren bir protokol. Bu durumlar çerçeveleri taşıyan bir overlay ya da köprülenmiş hizmet gerektirir ve o zaman VLAN üyeliği, döngü önleme ve arıza yönetimi uçtan uca konular haline gelir.

Bu çok daha büyük bir arıza alanıdır ve dosya paylaşımını çalıştırma çabasının rastlantısal sonucu değil, bilinçli bir tercih olmalıdır. Sıradan bir dosya sunucusu, veritabanı veya web uygulaması yetkilendirilmiş bir IP yoluna ihtiyaç duyar ve altında gerilmiş bir yayın alanı olmadan daha mutlu olacaktır.

VPN sözleşmesini erişilebilir önekler ve izin verilen hizmetler olarak yazın ve VLAN etiketini yalnızca yerel işlemlerin ona ihtiyaç duyduğu yerde kaydedin. Böylece her ofis, her değişikliği bir tünel yeniden tasarımına dönüştürmeden kendi anahtarlamasını yeniden numaralandırabilir.