Зошто мултикаст не преминува преку VPN без план

Две локации можат совршено да се достигнат преку јуникаст и сепак да се однесуваат како едната да не ја гледа најавата за откривање на печатачот, IPTV текот или отчукувањето на кластерот. Ова не е скршен тунел; ова е разликата помеѓу дестинација и група. Испораката на мултикаст бара модел на членство, состојба на препраќање по патеката и интерфејс подготвен да го носи сообраќајот, и ништо од тоа не доаѓа од јуникаст рута. Одењето од групата на апликацијата до еден работен примач е најкратката патека до одговор.

Започнете со групата и апликацијата

Прашајте која адреса на група ја користи апликацијата и за што е сообраќајот. Протокол за откривање што објавува услуги, тек за стриминг и поздравните пакети на протокол за рутирање се три различни проблеми со три различни прифатливи одговори. Самата адреса на групата го кажува опсегот: адресите во блокот за контрола на локалната мрежа не се наменети да бидат препратени надвор од врската со обично рутирање, а апликациите што ги користат обично претпоставуваат еден домен на емитување. Тек за стриминг на група со глобален опсег е различен дизајн од протокол за откривање што очекува секој уред да го чуе секое прашање, и само вториот се грижи за големината на доменот на емитување.

Одлучете дали барањето е услугата или механизмот за откривање, бидејќи тие одговори се разликуваат во цена за еден ред. Едниот бара адреса што не се менува; другиот бара домен на емитување проширен преку врска од широка мрежа со сето што произлегува од тоа.

Локалното откривање треба да запре

RFC 6762 опишаниот Multicast DNS е дизајниран околу една врска: прашањата одат до фиксна група, одговорите се праќаат до истата група, и протоколот се потпира на тоа дека секој учесник ги слуша сите. Рутерите не го препраќаат тој сообраќај стандардно, и тоа е дизајнерска одлука, а не пропуст. Границата постои за да не може уред во една зграда едноставно да се објави во друга. Тунел што навидум го поправа откривањето со тоа што ја носи групата насекаде ја отстрани таа граница за секоја апликација, не само за таа што имаше потреба од помош.

Повторувачи и рефлектори постојат, и тие се вистински услуги со вистински последици: секое име објавено на една локација станува видливо на другата, вклучително имиња на уреди што идентификуваат луѓе или опрема. Ако вистинското барање е одредена услуга да биде пронајдена, запис за услуга објавен во DNS е обично помалата промена, и открива едно име наместо тек од нив.

Три работи што и се потребни на рутираниот мултикаст

Рутираниот мултикаст бара три работи што работат заедно: примачи што се приклучуваат на групата, рутери што одржуваат состојба на препраќање за неа и тунел што ги третира адресите на групата како сообраќај што треба да се носи. Тунел со политика што наведува само јуникаст подмрежи ќе го отфрли сообраќајот на групата на границата на шифрирање, и затоа првиот симптом е често тишина наместо грешка. Интерфејс заснован на рути, како GRE или VTI тунел, носи што ќе испрати табелата за рутирање во него, што ја прави групата достапна штом постои состојбата на мултикаст.

Достапноста на изворот е втората половина. Протоколи за рутирање на мултикаст како PIM градат дрвја за дистрибуција проверувајќи дали патеката назад до изворот е очекуваната, па јуникаст рута што покажува на друго место го крши дрвото дури и кога членството во групата е точно. Инсталирањето рута за примачот не прави ништо за таа проверка, и тоа е грешката што дава пинг што работи и тек што пропаѓа. Прво проверете ја повратната патека на изворот, потоа додајте членство и само потоа погледнете ја апликацијата.

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

Првите две линии покажуваат на што се приклучил домаќинот и што препраќа јадрото, третата го покажува сопственото членство на апликацијата, а последната јуникаст патеката што ќе ја користи проверката на обратна патека. Нивното читање заедно разликува апликација што никогаш не се приклучила од мрежа што никогаш не препратила.

Докажете го со еден извор и еден примач

Пред да допрете конфигурација, потврдете дека апликацијата работи на еден сегмент. Ако не успее локално, рутирањето на мултикаст не е проблемот и ниту една промена на тунелот нема да помогне. Потоа повторете со еден примач преку тунелот и гледајте ги пакетите од двете страни на границата на шифрирање.

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

Пакети видливи внатре во тунелот, но отсутни надвор од него укажуваат на инкапсулација или политика; пакети видливи од двете страни без напредок во апликацијата укажуваат на членството на примачот или врзувањето на апликацијата. Држете ги снимките кратки и филтрирани, бидејќи широка мултикаст снимка на зафатен сегмент е главно шум.

Изберете адреса на услуга кога ви треба само услугата

Откривањето постои за да најде нешто што се движи. Сервер со стабилно име не бара откривање, а документирана адреса во приватен DNS одговара на вистинското прашање на корисникот без да прошири домен на емитување преку врска од широка мрежа. Истото размислување важи за печатачи, уреди и внатрешни веб услуги. Името во DNS е достапно од секоја локација што го бара додека не објавува ништо на локациите што не го бараат, и продолжува да работи кога уредот ќе биде заменет со друг со различна адреса.

Кога протокол навистина бара мултикаст, ограничете го на групата и на локациите што го бараат, документирајте зошто и преиспитајте ја одлуката кога апликацијата ќе се промени. Проширувањето на откривањето насекаде е лесно еднаш, и тешко се повлекува по една година уреди што тивко зависат од него.