OpenVPN üzerinden iki kart arasında yalıtılmış TAP köprüsü
Köprü, çerçeveleri üye bağlantı noktaları arasında iletir ve ana makine adresi köprünün kendisine aittir. Tezgâh bağlantı noktalarını yönetimi açığa çıkarmadan bağlayın.
İki geliştirme kartının, tezgâhları farklı binalarda olsa da tek bir Ethernet segmentini paylaşması gerekiyor. Tünel zaten var ve zaten Ethernet taşıyor, bu yüzden kalan iş üç komut gibi görünüyor ve öyle değil. Ana makinenin köprülenmiş bir çerçeveyle ne yaptığı, bilgisayarın kendi adresinin nereye ait olduğu ve köprünün hangi sınırı oluşturmadığı üç ayrı gerçektir ve ikincisini yanlış yapmak, bir laboratuvarın aralıklı çalışmasının ve yönetim erişiminin sessizce bozulmasının olağan nedenidir. Bu üç gerçeğin hiçbiri bir topoloji şemasında görünmez.
Aşağıdaki yol, iki Linux bilgisayar arasında kimliği doğrulanmış bir TAP bağlantısı, tezgâh başına bir özel kablolu bağlantı noktası ve deneyin parçası olmayan bir yönetim arayüzü varsayar. Sıra önemlidir: önce çerçeveler, sonra adresler, en son sınır.
Köprü gerçekte neyi taşır
Köprü, yazılımda gerçekleştirilmiş bir anahtardır. Hangi MAC adresinin hangi üye bağlantı noktasının arkasında göründüğünü öğrenir ve çerçeveleri üyeler arasında bir IP yönlendirme tablosuna bakmadan iletir. Bu tanımda bir alt ağ, bir ağ geçidi veya varsayılan bir yol yoktur, bu yüzden IP iletimini etkinleştirmek bu bağlantıyı oluşturmaz ve bu yüzden bir ping başarılı olurken diğer trafik hâlâ başarısız olabilir. Bir kart, yapılandırılmış hiçbir varsayılan yol olmadan eşine ulaşabilir; bu, ikinci katmanın üçüncü katman gibi davranmasını bekleyenleri şaşırtır.
Her bilgisayar köprüye bir kablolu bağlantı noktası ve TAP aygıtını aynı köprüye verir, böylece bir karttan gelen çerçeve yerel bağlantı noktasına girer, TAP aygıtına iletilir, tüneli geçer, eşin TAP aygıtına ulaşır ve eşin kartına iletilir. Tünel, herhangi bir üye bağlantı noktası gibidir ve köprü arkasında bir VPN olduğunu bilmez ve önemsemez. Bu simetri örneği kolay akıl yürütülür kılar: her tarafın laboratuvara bakan bir bağlantı noktası ve bir tünel bağlantı noktası vardır ve hiçbir taraf özel değildir.
Board A -- bench0 -- br-test -- tap-bench
| OpenVPN TAP
Board B -- bench0 -- br-test -- tap-benchİki bilgisayardaki aynı adlar yerel adlardır, paylaşılan nesneler değildir. Tezgâhlar arasında tek bir Ethernet yolu vardır, ikinci bir kablo ve döngüyü kapatan ikinci bir tünel yoktur; aynı MAC'i iki bağlantı noktasında gören bir köprü memnuniyetle daireler çizerek iletir.
Köprüye adres verin, üye bağlantı noktalarına değil
Bilgisayarın laboratuvar segmentindeki kimliği köprü aygıtına aittir. Üye bağlantı noktaları numarasız kalır, çünkü bağlantı noktası ileten bir üyedir ve üzerindeki bir adres aynı segmentin ikinci, rekabet eden sahibini yaratırdı. Bu, çoğu el yapımı tarifin yanlış yaptığı düzeltmedir: TAP aygıtına ve köprüye adres verirler, sonra eşin gerçekte hangisine ulaştığını merak ederler.
ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test upEş, farklı bir ana makine adresiyle aynı biçimi kullanır ve kartlar, ihtiyaç duyarlarsa bilgisayarın köprü adresini bir sonraki atlama olarak kullanarak aynı aralıkta adres alır. Plan üzerinde anlaşılana kadar belge aralıklarını kullanın ve aralığı, ofisin zaten yönlendirdiği hiçbir şeyle çakışmaması için ayırın. Herhangi bir bölümünü çalıştırmadan önce, üye bağlantı noktalarının artık adres, DHCP istemcisi ve başka bir köprüde üyelik taşımadığını doğrulayın ve TAP aygıtının adreslemesini tünel yapılandırmasına sahip olan şey üzerinden uyumlayın ki daha sonra bir adresi geri yüklemesin.
Tezgâh başına neden bir özel bağlantı noktası
Özel bir kablolu bağlantı noktası, deneyin ofis çapında bir değişikliğe dönüşmesini engelleyen şeydir. Yönetim arayüzü SSH, varsayılan yolu ve dış VPN bağlantısını taşır ve bunların hiçbiri amacı laboratuvar çerçevelerini taşımak olan bir köprüye ait değildir.
Bir yönetim bağdaştırıcısı bağlamak, ofis LAN'ini bir geliştirme kartından bir iletim kararı uzağa koyar ve ikinci katmanda kötü davranan bir kart, o segmentte istemeyeceğiniz türden bir aygıttır. Wi-Fi bağdaştırıcısı daha kötüdür: altyapı kipinde bir kablosuz arayüzü köprülemek Ethernet köprülemek gibi davranmaz ve arıza temiz değil kafa karıştırıcıdır.
Laboratuvar aralığını herhangi bir üretim DHCP kapsamının dışında tutun. Kartların daha sonra dinamik adreslemeye ihtiyacı olursa, tek bir havuzla tek yetkili dağıtıcı öngörülebilir kalan tek düzenlemedir; aynı segmentte yanıt veren iki sitenin sıradan yönlendiricileri kimsenin açıklayamadığı adresler üretir.
Köprünün oluşturmadığı sınır
Köprüleme yönlendirme değildir ve yalıtım da değildir. Köprüyü geçen çerçeveler, kurulu bridge-netfilter yoluna bağlı olarak ana makinenin filtreleme kancalarına hâlâ ulaşabilir, bu yüzden etkin politika varsayılmak yerine denetlenmelidir. Bir çerçeve kayboldu diye güvenlik duvarını devre dışı bırakmak, belirli bir hatayı genel bir hatayla değişir.
Köprü ile her yönetim veya uplink arayüzü arasındaki IP iletimi kapalı kalmalı veya açıkça reddedilmelidir ve bu, köprü üyeliğinden ayrı bir denetimdir. Bilgisayarın laboratuvar adresini ağ geçidi olarak seçen bir kart tam olarak bunu sınar: yönetim geçişi başarılı olursa, amaçladığınız sınır hiç var olmamıştır.
İki aile daha açık bir kararı hak ediyor. Adres planı köprüyü yalnızca IPv4 yapmaz, bu yüzden IPv6 ve diğer EtherType'lar kendi planlarına veya filtrelerine ihtiyaç duyar. Ve başarılı bir ping, kartın keşif yayınlarının, multicast gruplarının veya jumbo çerçevelerinin yolu geçip geçmeyeceği hakkında hiçbir şey söylemez, çünkü bunlar farklı varsayılanlara sahip farklı trafik sınıflarıdır.
Son olarak, taşıma ve gizlilik iki ayrı satın almadır. TAP Ethernet taşır; OpenVPN hizmeti çevresindeki korumayı sağlar. Bir VXLAN katmanı da Ethernet taşır ve kendi başına gizlilik sağlamaz, bu yüzden birini diğeriyle değiştirmek, topoloji şeması aynı görünse bile güvenlik özelliklerini değiştirir.
Kalıcılık ve bunu kanıtlayan testler
Bağlandıktan sonra bir kez yazılan bir komut yapılandırma değildir. Köprüyü, bağlantı noktası üyeliğini ve tek ana makine adresini bilgisayarın mevcut ağ yöneticisi üzerinden kalıcı yapın ve bağlantıyı TAP aygıtının görünmesine bağlayın ki yeniden bağlanma üyesi kaybolmuş bir köprü bırakmasın.
bridge link show
ip -d link show br-test
bridge fdb show br br-test | headArdından kartların iki yönde gerçekte neye ihtiyaç duyduğunu test edin, tüneli yeniden bağlayın ve onaylanmış kurtarma planına göre bir bilgisayarı yeniden başlatın. Ardından üç şeyi doğrulayın: yönetim erişimi hâlâ bağımsız çalışıyor, yinelenen bir laboratuvar adresi görünmüyor ve beklenmeyen bir üretim arayüzü köprüye katılmadı. Bu birleşim, deneyin kendi tezgâhının içinde kaldığının kanıtıdır.