Multicast neden bir plan olmadan VPN'den geçmez

Erişilebilirlik bir unicast meselesidir. Bir köprü veya aktarıcı eklemeden önce grubu, kapsamını, iletim durumunu ve tek bir kaynaktan tek bir alıcıya giden tek bir yolu inceleyin.

İki site unicast ile birbirine kusursuz ulaşabilir ve yine de biri yazıcının keşif duyurusunu, IPTV akışını veya kümenin kalp atışını görmüyormuş gibi davranabilir. Bu bozuk bir tünel değil; hedef ile grup arasındaki farktır. Multicast teslimi için üyelik modeli, yol boyunca iletim durumu ve trafiği taşımaya istekli bir arayüz gerekir ve bunların hiçbiri unicast yolundan gelmez. Uygulamanın grubundan çalışan tek bir alıcıya gitmek, bir yanıta giden en kısa yoldur.

Grupla ve uygulamayla başlayın

Uygulamanın hangi grup adresini kullandığını ve trafiğin ne için olduğunu sorun. Hizmetleri duyuran bir keşif protokolü, bir akış beslemesi ve bir yönlendirme protokolünün merhaba paketleri, üç farklı kabul edilebilir yanıtı olan üç farklı sorundur. Grup adresinin kendisi kapsamı söyler: yerel ağ kontrol bloğundaki adresler sıradan yönlendirme ile bağlantı dışına iletilmek üzere değildir ve bunları kullanan uygulamalar genellikle tek bir yayın etki alanı varsayar. Küresel kapsamlı bir grupta akış beslemesi, her cihazın her sorguyu duyacağını bekleyen bir keşif protokolünden farklı bir tasarımdır ve yayın etki alanının boyutuyla yalnızca ikincisi ilgilenir.

Gereksinim hizmet mi yoksa keşif mekanizması mı, buna karar verin, çünkü bu iki yanıt maliyet açısından bir kat fark eder. Biri değişmeyen bir adres ister; diğeri geniş alan bağlantısı boyunca genişletilmiş yayın etki alanı ve bundan doğan her şeyi ister.

Bağlantı yerel keşif durmalıdır

RFC 6762 içinde tanımlanan Multicast DNS tek bir bağlantı etrafında tasarlanmıştır: sorgular sabit bir gruba gider, yanıtlar aynı gruba gönderilir ve protokol her katılımcının herkesi duymasına dayanır. Yönlendiriciler bu trafiği varsayılan olarak iletmez ve bu bir tasarım kararıdır, gözden kaçma değildir. Sınır, bir binadaki cihazın diğerine öylece kendini duyuramaması için vardır. Grubu her yere taşıyarak keşfi düzeltiyor gibi görünen bir tünel, bu sınırı yalnızca yardıma ihtiyacı olan uygulamadan değil her uygulamadan kaldırmıştır.

Yineleyiciler ve yansıtıcılar vardır ve gerçek sonuçları olan gerçek hizmetlerdir: bir sitede duyurulan her ad diğerinde görünür hale gelir, kişileri veya ekipmanı tanımlayan cihaz adları dahil. Gerçek gereksinim belirli bir hizmetin bulunabilmesi ise, DNS'te yayımlanan bir hizmet kaydı genellikle daha küçük değişikliktir ve adların akışı yerine tek bir adı açığa çıkarır.

Yönlendirilen multicast'in ihtiyaç duyduğu üç şey

Yönlendirilen multicast, birlikte çalışan üç şeye ihtiyaç duyar: gruba katılan alıcılar, grup için iletim durumunu tutan yönlendiriciler ve grup adreslerini taşınacak trafik olarak ele alan bir tünel. Politikasında yalnızca unicast alt ağları listelenen bir tünel, grup trafiğini şifreleme sınırında düşürür ve bu yüzden ilk belirti çoğu zaman hata değil sessizliktir. GRE veya VTI tüneli gibi yol tabanlı bir arayüz, yönlendirme tablosunun içine gönderdiğini taşır ve bu da multicast durumu var olduğunda grubu erişilebilir kılar.

Kaynağa erişilebilirlik ikinci yarıdır. PIM gibi multicast yönlendirme protokolleri, kaynağa geri dönüş yolunun beklenen olduğunu denetleyerek dağıtım ağaçları kurar, dolayısıyla başka bir yeri gösteren bir unicast yolu grup üyeliği doğru olsa bile ağacı bozar. Alıcı için bir yol kurmak bu denetim için hiçbir şey yapmaz ve çalışan ping ile başarısız akışı üreten hata budur. Önce kaynağın dönüş yolunu doğrulayın, sonra üyeliği ekleyin ve ancak ondan sonra uygulamaya bakın.

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

İlk iki satır, ana makinenin neye katıldığını ve çekirdeğin neyi ilettiğini gösterir, üçüncü satır uygulamanın kendi üyeliğini, son satır ise ters yol denetiminin kullanacağı unicast yolunu gösterir. Bunları birlikte okumak, hiç katılmayan bir uygulamayı hiç iletmeyen bir ağdan ayırır.

Tek kaynak ve tek alıcıyla kanıtlayın

Bir yapılandırmaya dokunmadan önce uygulamanın tek bir segmentte çalıştığını doğrulayın. Yerelde başarısız olursa sorun multicast yönlendirmesi değildir ve hiçbir tünel değişikliği yardımcı olmaz. Ardından tünel boyunca tek bir alıcıyla tekrarlayın ve şifreleme sınırının iki yanındaki paketleri izleyin.

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

Tünelin içinde görünen ama dışında bulunmayan paketler kapsüllemeye veya politikaya işaret eder; iki yanda da görünen ama uygulamada ilerleme olmayan paketler alıcının üyeliğine veya uygulamanın bağlanmasına işaret eder. Kayıtları kısa ve süzülmüş tutun, çünkü yoğun bir segmentte geniş bir multicast kaydı çoğunlukla gürültüdür.

Yalnızca hizmete ihtiyacınız varsa hizmet adresini seçin

Keşif, hareket eden bir şeyi bulmak için vardır. Kararlı bir ada sahip sunucu keşfe ihtiyaç duymaz ve özel DNS'te belgelenmiş bir adres, yayın etki alanını geniş alan bağlantısı boyunca genişletmeden kullanıcının gerçek sorusunu yanıtlar. Aynı akıl yürütme yazıcılar, cihazlar ve iç web hizmetleri için de geçerlidir. DNS'teki bir ad, ihtiyaç duyan her siteden erişilebilirken ihtiyaç duymayan sitelere hiçbir şey duyurmaz ve cihaz farklı adresli biriyle değiştirildiğinde de çalışmaya devam eder.

Bir protokol gerçekten multicast gerektiriyorsa, onu grupla ve ihtiyaç duyan sitelerle sınırlayın, nedenini belgeleyin ve uygulama değiştiğinde kararı yeniden gözden geçirin. Keşfi her yere yaymak bir kez kolaydır ve ona sessizce bağımlı cihazlarla bir yıl geçtikten sonra geri almak zordur.

İlgili makaleler