OpenVPN üzerinden SSM: bir kaynağı ve grubu baştan sona izlemek

Bir akış ve bir alıcı seçin, sonra multicast'ı bir kategori olarak test etmek yerine bu çifti her atlama boyunca takip edin. Kaynağa özgü tasarım tam olarak dört yerden birinde başarısız olur: alıcı hiç katılmadı, yönlendirici paketi dönüş yolunda reddetti, çekirdeğin durumu yok ya da tünel hiçbir kopya teslim etmedi. Bu sırayla çalışmak atlama başına birkaç dakika sürer ve dördünden hangisine gerçekten sahip olduğunuzu söyler.

Önce kaynağı, grubu ve alıcıyı sabitleyin

Herhangi bir cihaza dokunmadan önce üç değer yazın: gönderecek kaynak adresi, alıcının katılacağı grup adresi ve alıcının bulunduğu alt ağ. Örnek bir IPv4 akışı için 10.50.0.10 kaynağı ve 232.20.30.40 grubu, kaynağa özgü tasarıma uyan çift türüdür. Bu üç değerden daha belirsiz hiçbir şey test edilemez.

232/8 aralığı kaynağa özgü multicast için ayrılmıştır ve model RFC 4607 belgesinde açıklanmıştır. SSM çalıştırdığınızı düşünürken grubunuz bu aralığın dışındaysa durun ve dağıtımın gerçekte ne amaçladığını doğrulayın, çünkü alıcının katılması ve yönlendiricinin iletme kararı ikisi de modelin tutarlı olmasına bağlıdır.

Alıcının kaynağa katıldığını doğrulayın

Yalnızca gruba yönelik bir üyelik raporu, kaynağa özgü katılma değildir. Alıcıya hangi kaynağı istediğini sorun ve ilk atlama yönlendiricisinde grup durumuna bakarak bir kaynak listesinin görünüp görünmediğini kontrol edin. Rapor hiçbir kaynak taşımıyorsa yönlendirici bunu herhangi bir kaynaktan katılma olarak ele alır ve tüm tasarım sessizce planlamadığınız bir şeye dönüşür.

Bir Linux alıcısında soketin gerçekte neye abone olduğunu ve çekirdeğin ne kaydettiğini kontrol edin. Uygulamanın yapılandırma dosyası kanıt değildir; üyelik tablosu kanıttır. Alıcı gerçekten çalışırken okuyun, çünkü bir girdi onu oluşturan süreç çıktıktan sonra kısa süre kalabilir. Önceki bir testten kalan eski girdi, yanlış güvenin güvenilir kaynağıdır.

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

Katılma beklenen kaynakla birlikte varsa yönlendiricilere geçin. Yoksa hiçbir tünel yapılandırması yardımcı olmaz, çünkü iletilecek bir şey yoktur.

Tünele bakmadan önce dönüş yolunu doğrulayın

Multicast yönlendirme bir dönüş yolu denetimi yapar ve unicast rotasının işaret ettiğinden farklı bir arayüze gelen paket düşürülür. Bu, açıkça gönderilen bir akışın sonraki atlamaya hiç ulaşmamasının en yaygın nedenidir ve uygulama düzeyinde hiçbir yararlı hata üretmez.

Kaynağa bakan yönlendiricide, kaynağa doğru rotayı paketlerin gerçekte geldiği arayüzle karşılaştırın. Alıcıya bakan yönlendiricide, alıcının kendi alt ağı için aynısını yapın ve giden arayüz listesinin oraya giden bağlantıyı içerdiğini doğrulayın. Herhangi bir yönde uyumsuzluk RPF hatasıdır, üyelik hatası değildir.

Sonra kaynağın TTL değerinin tasarladığınız yönlendirilmiş atlamaları atlatmaya yetecek kadar büyük olduğunu doğrulayın. İlk yönlendiricide çalışıp ikincide ölen bir akış çoğu zaman TTL sorunudur, politika sorunu değildir.

Yapılandırma yerine çekirdeğin multicast durumunu okuyun

Yapılandırma ne istediğinizi söyler; çekirdek ne olduğunu söyler. Her Linux atlamasında multicast yönlendirme girdilerini okuyun ve tam kaynak-grup çifti için gelen ve giden arayüz listesinin var olduğunu doğrulayın. Grup için joker karakterli kaynakla olan girdi başka bir nesnedir ve kaynağa özgü bir akışı açıklamaz.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Yönlendirme daemonları bu durumun üzerinde kendi görüşlerini tutar ve onu yazdıran komut hangi uygulamanın kurulu olduğuna bağlıdır. İlke sabittir: daemona çift için üst akış girdisini sorun, sonra çekirdeğe iletme girdisinin olup olmadığını sorun. Çekirdekte girdi yokken ilettiğini sanan bir daemon, o ana makinede yapılandırma kapsamı sorunudur.

İkisi uyuşmadığında VPN'i değil ana makineyi düzeltin. Sorduğunuz akışı iletmeyen bir atlamayı aşağı akışta hiçbir şey telafi edemez. Akış çalışırken her atlama için çifti, gelen arayüzü ve giden listeyi kaydedin. Bu kayıt, sonraki hatayı yeni bir soruşturma yerine karşılaştırmaya dönüştürür.

Tünelin gerçekte nasıl çoğalttığına karar verin

Burada VPN üzerinden multicast rutin olmaktan çıkar. Noktadan noktaya tünel, paketi diğer uçtaki tek eşe teslim eder, bu yüzden bir kopya tam olarak bir istemciye ulaşır. Köprülenmiş segment daha çok paylaşılan bir bağlantı gibi davranır, çünkü tünel çerçeveyi taşır ve köprü neyin taşacağına karar verir. Bunlar farklı teslimat modelleridir ve ikincisini varsayıp birincisini çalıştıran bir tasarım bir alıcı için çalışıyor görünecek, sonraki için başarısız olacaktır.

Çok noktalı bir sunucu üzerinden birden fazla alıcı için çoğaltma açıkça tasarlanmalıdır. Ağ geçidine bir multicast rotası kurmak, VPN sunucusuna hangi eşlerin kopya alması gerektiğini öğretmez ve istemci tarafındaki hiçbir rota bu kararı onun yerine vermez. Gereksinim çok sayıda alıcı olduğunda desteklenen çoğaltmayı veya bilinçli olarak seçilmiş bir alternatifi kullanın ve hangisini seçtiğinizi yazın.

Son olarak, alıcıda dar bir gözlem altında doğrulayın: tam kaynak, grup ve bağlantı noktası, beklediğiniz arayüzde, yetkili bir alıcı katılıyken. SSM bir gönderici seçer ve seçim o göndericinin kimlik doğrulaması değildir, başka multicast trafiğinin aynı politikayı geçmesine izin de değildir.