Чаму мультыкаст не пераходзіць праз VPN без плана

Два сайты могуць ідэальна дасягаць адзін аднаго праз юнікаст і ўсё ж паводзіць сябе так, нібы адзін з іх не бачыць аб'яву выяўлення прынтара, паток IPTV або сігнал жыццядзейнасці кластара. Гэта не зламаны тунэль; гэта розніца паміж прызначэннем і групай. Дастаўка мультыкасту патрабуе мадэлі ўдзелу, стану перасылкі ўздоўж шляху і інтэрфейсу, гатовага несці трафік, і нічога з гэтага не паходзіць ад юнікаст-маршруту. Рух ад групы праграмы да аднаго працаздольнага атрымальніка — найкарацейшы шлях да адказу.

Пачніце з групы і праграмы

Спытайце, які адрас групы выкарыстоўвае праграма і для чаго патрэбны трафік. Пратакол выяўлення, які аб'яўляе службы, патокавая перадача і пакеты прывітання пратаколу маршрутызацыі — гэта тры розныя праблемы з трыма рознымі прымальнымі адказамі. Сам адрас групы паведамляе вобласць: адрасы ў блоку кіравання лакальнай сеткай не прызначаны для перасылкі за межы канала звычайнай маршрутызацыяй, а праграмы, якія іх выкарыстоўваюць, звычайна мяркуюць адзін шырокавяшчальны дамен. Патокавая перадача на групе з глабальнай вобласцю — гэта іншы дызайн, чым пратакол выяўлення, які чакае, што кожная прылада пачуе кожны запыт, і толькі другі клапоціцца пра памер шырокавяшчальнага дамена.

Вырашыце, ці патрабаванне — гэта служба, ці механізм выяўлення, бо гэтыя адказы адрозніваюцца па цане на парадак. Адзін просіць адрас, які не змяняецца; другі просіць шырокавяшчальны дамен, пашыраны праз канал глобальнай сеткі з усім, што з гэтага вынікае.

Лакальнае выяўленне павінна спыняцца

Multicast DNS, апісаны ў RFC 6762, распрацаваны вакол аднаго канала: запыты ідуць да фіксаванай групы, адказы адпраўляюцца ў тую ж групу, і пратакол разлічвае на тое, што кожны ўдзельнік чуе ўсіх. Маршрутызатары не перасылаюць такі трафік па змаўчанні, і гэта рашэнне дызайну, а не недагляд. Мяжа існуе для таго, каб прылада ў адным будынку не магла проста так аб'явіць сябе ў іншым. Тунэль, які нібыта выпраўляе выяўленне, носячы групу ўсюды, зняў гэту мяжу для кожнай праграмы, а не толькі для той, якой патрэбна была дапамога.

Рэтранслятары і адбівальнікі існуюць, і гэта сапраўдныя службы з сапраўднымі наступствамі: кожнае імя, аб'яўленае на адным сайце, становіцца бачным на другім, уключаючы імёны прылад, якія ідэнтыфікуюць людзей або абсталяванне. Калі ж рэальнае патрабаванне ў тым, каб пэўную службу можна было знайсці, запіс службы, апублікаваны ў DNS, звычайна меншае змяненне, і ён раскрывае адно імя замест іх патоку.

Тры рэчы, патрэбныя маршрутызаванаму мультыкасту

Маршрутызаваны мультыкаст патрабуе трох рэчаў, якія працуюць разам: атрымальнікаў, што далучаюцца да групы, маршрутызатараў, што падтрымліваюць стан перасылкі для яе, і тунэлю, які ставіцца да адрасоў групы як да трафіку, які трэба несці. Тунэль з палітыкай, дзе пералічаныя толькі юнікаст-падсеткі, скідзе трафік групы на мяжы шыфравання, і менавіта таму першы сімптом часта цішыня, а не памылка. Інтэрфейс на аснове маршрутаў, такі як тунэль GRE або VTI, нясе тое, што пасылае ў яго табліца маршрутызацыі, і гэта робіць групу дасяжнай, калі стан мультыкасту ўжо ёсць.

Дасяжнасць крыніцы — другая палова. Пратаколы маршрутызацыі мультыкасту, такія як PIM, будуюць дрэвы размеркавання, правяраючы, што шлях назад да крыніцы — чаканы, таму юнікаст-маршрут, які паказвае ў іншае месца, ламае дрэва, нават калі ўдзел у групе правільны. Усталяванне маршруту для атрымальніка нічога не робіць для гэтай праверкі, і гэта памылка, якая дае працаздольны ping і збойны паток. Спачатку праверце зваротны шлях да крыніцы, потым дадайце ўдзел і толькі пасля гэтага глядзіце на праграму.

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 дасяжнае з кожнага сайта, якому яно патрэбнае, і нічога не аб'яўляе сайтам, якім яно не патрэбнае, і яно працягвае працаваць, калі прыладу замяняюць на іншую з іншым адрасам.

Калі пратакол сапраўды патрабуе мультыкасту, абмяжуйце яго групай і сайтамі, якім ён патрэбны, задокументуйце прычыну і перагледзьце рашэнне, калі праграма зменіцца. Пашырыць выяўленне ўсюды — лёгка зрабіць адзін раз, і цяжка адмяніць пасля года прылад, якія ціха на яго спадзяюцца.