SoftEther kaskadı: iki sanal hub’ı bilerek bağlamak
Kaskad, yerel bir hub’ı yapılandırılmış bir kimlik altında uzak bir hub’a bağlar. Çıkış düğümü değildir ve o hub’ların hâlihazırda köprilediği her şeyi taşır.
Bir kaskadla birbirine bağlanan iki SoftEther hub tek bir yayın alanını paylaşır, bu yüzden bir döngü ya da ikinci bir DHCP sunucusu artık yerel bir hata olmaktan çıkıp ortak bir hata olur. Risk modelinin tamamı budur. Kaskadın kendisi yapılandırılmış bir istemci ilişkisidir: yerel sanal hub, o sunucunun yetkilendirdiği bir kimlik altında uzak bir sunucunun hub’ına dışarı bağlanır. Daha büyük bir sanal ağ için bir yapı taşıdır, asla internet çıkışı değildir.
1. Bağlantının neyi taşıması gerektiğine karar verin
Özellikten değil, gereksinimden başlayın. Kaskad hub’lar arasında ikinci katman çerçevelerini taşır ve iki sahanın tek bir Ethernet segmenti gibi görünmesi gerektiğinde istediğiniz budur. Gereksinim yalnızca birkaç alt ağa yönlendirilmiş erişimse, yönlendirilmiş bir yol daha basittir ve görülmesi daha kolay biçimlerde başarısız olur. Bir kaskad seçmek sizi ortak yayına, ortak keşfe ve tek bir döngü topolojisine bağlar.
Gereksinimi bir sunucuya dokunmadan önce tek satırda yazın: hangi sistemler aynı kabloda görünmeli ve hangileri yalnızca bir yol gerektiriyor. «Yol» diye yanıt veren her şey kaskadın dışındadır. Bu tek cümle, yinelenen adres hizmetleriyle biten tasarımların çoğunu önler.
2. Yetki veren kimliğin kapsamını belirleyin
Bir sunucuyu yöneten kimlik bilgileri ile kaskadın bağlanmak için kullandığı kimlik farklı sırlardır ve bunları karıştırmak uzun kuyruklu yaygın bir kısa yoldur. Uzak hub’ın bu kaskadın bağlanmasına izin veren bir kullanıcı veya ilke girdisine ihtiyacı vardır. O girdi yetkilendirmedir; başarılı bir oturum açma, uzak hub’ın arkasında ne olduğu hakkında hiçbir şey söylemez.
Hangi hub’ın başlattığını, hangi uzak hub’a katıldığını ve uzak kimliğin neye ulaşabileceğini kaydedin. Bağlanmadan önce iki mimariyi karşılaştırın:
| Requirement | Routed path | Cascaded segment |
|---|---|---|
| Broadcast domain | Separate on each side | Shared across the link |
| Address service | One DHCP server per side | Must not run two on one domain |
| Loop risk | Route loops only | Layer-two loops if segments overlap |
Her iki uçtaki kimlik bilgilerini ve kurtarma talimatlarını güncel tutun. Uzak hub’daki bir parola değişikliği veya ilke düzenlemesi, yerel kullanıcılarınıza dokunmadan kaskadı bozar ve arıza genellikle açık ama boş bir bağlantı olarak görünür.
3. Hub’ın hâlihazırda ne taşıdığını inceleyin
Bir hub nadiren yalıtılmıştır. Zaten fiziksel bir bağdaştırıcıya köprü kuruyor, sanal bir yönlendirici üzerinden yönlendiriyor veya başka bir yere kaskadlıyor olabilir ve bu bağlantıların her biri yeni ilişkiye taşınır. «Yalnızca iki hub bağladık» ifadesinin bu kadar sık «neden bu iki saha artık tek bir segment» sorusuna dönüşmesinin nedeni budur.
Aynı fiziksel segmente köprülenip sonra birbirine kaskadlanan iki hub bir döngü oluşturur. Yayılan ağaç ekleyin ya da bunu kurmayın. Aynı sınav, hedefe başka bir kaskad üzerinden ulaşan hub için de geçerlidir: ikinci bağlantı kapasite eklemez, bir yol ekler.
Bir yol eksik diye bağlantı eklemeyin; yolu düzeltin. Önce topolojiyi kâğıda çizin, her köprü ve kaskad dahil, çünkü şema iki dakika sürer ve döngülerin çoğunu oluşmadan yakalar.
4. Katılmadan önce adreslemeyi düzene koyun
Birleşen segmentler yinelenen alt ağları getirir ve yinelenen DHCP sunucuları klasik belirtidir: istemciler ilk yanıt veren sunucudan kiralama alır, bu yüzden davranış rastgele görünür ve yeniden başlatmalar arasında yer değiştirir. Hangi tarafın adres atamasına sahip olduğuna önceden karar verin ve uzak segmente yerel hiçbir şeyle çakışmayan bir aralık verin. Diğer DHCP hizmetini kaskad çevrimiçi olmadan önce kapatın, ilk şikâyetten sonra değil.
DNS ayrı bir sorudur. Bir kaskad çerçeve taşır; çözümleyicileri yapılandırmaz ve yerel tarafta çözülen bir ad, bağlantı üzerinden çözülmeyebilir. Sorguyu IP yolundan ayrı test edin, çünkü çalışan bir ping ikisinden yalnızca birini kanıtlar.
5. Gerçek bir kaynakla kanıtlayın
Amaçlanan uzak segmentte izin verilen bir hizmet seçin ve yanıtın kaskad üzerinden geri geldiğini doğrulayın. Sonra ad çözümü için tekrarlayın. Hedef yayınla keşfe dayanıyorsa, tek bir kablo yerine köprülenmiş bağlantıda farklı davranış bekleyin ve bunu kusur olarak kaydetmek yerine planlayın.
Son olarak topolojiyi yazın: hangi hub nereye kaskadlanıyor, hangi kimlik buna yetki veriyor, hangi segmentler köprülenmiş ve her birinde adres ataması kime ait. Bu not, bir sonraki kişinin var olduğunu bilmediği bir segmenti düşürmeden bir ilkeyi değiştirmesini sağlar.