ESXi konuk VPN: yönlendirme mi köprüleme mi — port grubundan önce karar verin
Yönlendirilen TUN dönüş yolları gerektirir; köprülenen TAP katman 2 erişilebilirliği ve daha geniş bir port grubu ilkesi gerektirir. promiscuous modunu genişletmeden önce rolü belirleyin.
Paketleri yönlendirin ya da Ethernet alanını genişletin: port grubu değişikliği bu seçimin ardından gelir. Özel adres taşıyan bir uygulama açısından sonuçlar aynı görünebilir, oysa hipervizör gereksinimleri hiç benzemez. Bu yüzden önce port grubu genişletilir, tasarım sorusu ikinci sırada yanıtlanır; genellikle bir broadcast fırtınasından sonra. Bu kontrolleri sırayla yapın ve gereksinim hâlâ belirsizken durun, çünkü hiçbir port grubu ayarı hiç seçilmemiş bir tasarımı düzeltmez.
Karar hizmetin sahibine aittir; hipervizör yapılandırması onu uygulamalı, kazara belirlememelidir.
Uzak ucun gerçekte neye ihtiyacı olduğunu kontrol edin
Uzak istemcilerin erişmesi gereken hizmetleri ve kullandıkları protokolleri listeleyin. Liste bilinen öneklerdeki birkaç TCP hizmetiyse yönlendirme yeter. Bir şey gerçekten katman 2 komşuluğu gerektiriyorsa — broadcast'e bağlı keşif, IP dışı protokoller, ağ geçidini kabul etmeyen bir cihaz — yönlendirme bunu taklit edemez ve bu erken söylenmelidir. O listedeki IP dışı girdiler konusunda dürüst olun, çünkü yönlendirilen tasarımın bir hafta sonra sessizce başarısız olduğu yer orasıdır.
Sonra istemci havuzunu kontrol edin. Yönlendirilen tasarım bir adres aralığı ve uzak tarafta açık bir dönüş yolu gerektirir; köprülenen tasarım genişletilmiş Ethernet alanının adres tahsisi ve yalıtıma sahip olmasını gerektirir. Hangisini seçerseniz seçin, bu VM dışındaki biri bunu kabul etmelidir.
Her tasarım sanal ağdan ne ister
İki tasarım sanal ağın neye dayanması gerektiğinde farklıdır ve tablo bunu görmenin en kısa yoludur:
| Tasarım | Konuk tarafındaki rol | Sanal ağın barındırması gereken | Yanlış seçimde hata biçimi |
|---|---|---|---|
| Yönlendirilen TUN | Ayrı önekler arasında yönlendirici | Yönlendirilen istemci havuzu ve uzak tarafta dönüş yolları | İstemciler ağ geçidine ulaşır ama arkasındaki hizmete asla ulaşamaz |
| Köprülenen TAP | Katılan istemciler için katman 2 köprüsü | Ek Ethernet kimlikleri, broadcast trafiği ve VLAN kuralları | vSwitch çerçeveleri düşürür ya da tasarım kimsenin onaylamadığı bir promiscuous modu gerektirir |
Yönlendirme broadcast alanını olduğu yerde bırakır ve hangi hizmetlerin ağ geçidini aştığını sınırlamak için doğal bir yer verir. Köprüleme sınırı taşır: istemciler genişletilmiş Ethernet alanının katılımcısı olur ve adres tahsisi, yalıtım ve herhangi bir katman 2 ilkesi artık onlara uygulanır. Seçilen satırı değişiklik kaydına yazın. «Yönlendirilen TUN, istemci havuzu 10.90.0.0/24, çekirdekte dönüş yolu» gibi bir cümle, sonraki mühendisin tasarımı port grubu ayarlarından yeniden tartışmasını önler.
Kim kimin çerçevelerini görebilmeli
Port grubuna dokunmadan önce platform sahibine bir soru sorun: tasarım bu VM'in başka katılımcılara adreslenmiş çerçeveler almasını gerektiriyor mu? Yanıt hayırsa bu bölümde hiçbir şey geçerli değildir, çünkü yönlendirilen TUN o görünürlüğe asla ihtiyaç duymaz. Yanıt evetse, Broadcom'un promiscuous modu kılavuzu önemli olan okumadır: VM'in vSwitch'ten ne kadar fazlasını görebildiğini açıklar ve bu ilkenin tek bir port grubuyla sınırlandırılmasını önerir.
Bunu izin belgesi değil gereksinim kontrolü olarak ele alın. Köprüleme ihtiyacı yazıya geçtiğinde ayarı tek bir ayrılmış bağlantı için açın, başka her yerde kapalı bırakın. Başka bir köprü örneğinden kopyalanan geniş VLAN trunk, kimsenin kaldırmayı hatırlamadığı kısımdır ve tek VLAN'lı tasarım tek VLAN'lı kalmalıdır.
Hangi port grubunun değiştiğini ve nedenini, tasarım satırını yazdığınız yere kaydedin. Bu ikili bir sonraki denetimi mümkün kılar.
Konuğun nesnelerini açık tutun
Linux içinde köprü üyeliği ve adres sahipliği ayrı nesnelerdir ve bunları karıştırmak kafa karıştıran yarı çalışan durumu yaratır. Adresleri köprü arayüzüne veya yönlendirilen tünele atayın, aynı yolun iki tarafına değil, ve üye portları IP yapılandırmasından uzak tutun.
Bir alt ağı bağımsız olarak yönlendirilen TUN'a ve ilgisiz bir Ethernet arayüzüne koymaktan kaçının. Bu yapılandırma aynı öneke iki yol, asimetrik yanıtlar ve iki yoldan hiçbirini anmayan bir flapping destek başlığı üretir. Konuk ayrıca kapsayıcıları veya yerel bir hipervizörü barındırıyorsa, bunların zaten aynı uplink'e köprülenmediğini kontrol edin. Tek NIC üzerinde iki köprü bir tasarımdır, değişiklik penceresinde keşfetmek isteyeceğiniz bir kaza değildir.
ping ile değil, paket yoluyla doğrulayın
Yalnızca erişilebilirliği değil gerçek yolu doğrulayın. Bir istemciden hangi kaynak adresin uzak hizmete ulaştığını, ardından yanıtın aynı yoldan döndüğünü doğrulayın. Konukta belirli akış için yönlendirme sayaçlarını kontrol edin ve port grubunda seçilen tasarımın gerektirdiğinden fazla görünürlük etkinleştirilmediğini doğrulayın.
Son olarak hata yönünü test edin. Tüneli durdurun veya istemciyi ayırın ve trafiğin kullanılmadığını düşündüğünüz yönlendirilmiş bir yola sessizce düşmediğini kontrol edin, çünkü o düşüş köprülenen tasarımın sessizce istenmeyen bir yönlendiriciye dönüşme biçimidir.