SSM праз OpenVPN: адна крыніца і група ад пачатку да канца

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

Спачатку замацуйце крыніцу, групу і атрымальніка

Запішыце тры значэнні, перш чым дакранацца любой прылады: адрас крыніцы, якая будзе слаць, адрас групы, да якой далучыцца атрымальнік, і падсетку, дзе жыве атрымальнік. Для ілюстрацыйнага патоку IPv4 крыніца 10.50.0.10 і група 232.20.30.40 — гэта якраз тая пара, што падыходзіць для дызайну, спецыфічнага для крыніцы. Усё, што не вызначана гэтымі трыма значэннямі, праверыць немагчыма.

Дыяпазон 232/8 зарэзерваваны для multicast, спецыфічнага для крыніцы, і мадэль апісана ў RFC 4607. Калі ваша група знаходзіцца па-за гэтым дыяпазонам, а вы лічыце, што запускаеце SSM, спыніцеся і пацвердзіце, што насамрэч мае на ўвазе разгортванне, бо далучэнне атрымальніка і рашэнне маршрутызатара аб перасылцы абодва залежаць ад узгодненасці мадэлі.

Праверце, што атрымальнік далучыўся да крыніцы

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

На атрымальніку Linux праверце, на што фактычна падпісаўся сокет і што запісала ядро. Канфігурацыйны файл праграмы — не доказ; табліца сяброўства — доказ. Чытайце яе, пакуль атрымальнік фактычна працуе, бо запіс можа яшчэ трохі трымацца пасля выхаду працэсу, які яго стварыў. Састарэлы запіс з ранейшага тэсту — надзейная крыніца ілжывай упэўненасці.

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

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

Праверце зваротны шлях, перш чым глядзець на тунель

Маршрутызацыя multicast выконвае праверку зваротнага шляху, і пакет, які прыйшоў на інтэрфейс, адрозны ад таго, на які паказвае unicast-маршрут, адкідаецца. Гэта самая частая прычына, чаму паток, які відавочна сябе шле, ніколі не дасягае наступнага хопа, і гэта не дае ніякай карыснай памылкі на ўзроўні праграмы.

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

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

Чытайце стан multicast у ядры, а не канфігурацыю

Канфігурацыя кажа, што вы папрасілі; ядро кажа, што адбываецца. На кожным хопе Linux чытайце запісы маршрутызацыі multicast і пацвердзіце, што для дакладнай пары крыніца-група існуе спіс уваходных і выходных інтэрфейсаў. Запіс для групы з крыніцай-шаблонам — гэта іншы аб’ект, і ён не растлумачыць паток, спецыфічны для крыніцы.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

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

Калі яны разыходзяцца, выпраўляйце хост, а не VPN. Нішто ніжэй па патоку не кампенсуе хоп, які не перасылае паток, пра які вы пыталіся. Запісвайце пару, уваходны інтэрфейс і выходны спіс для кожнага хопа, пакуль паток працуе. Гэты запіс ператварае наступны збой у параўнанне замест новага расследавання.

Вырашыце, як тунель фактычна рэплікуе

Менавіта тут multicast праз VPN перастае быць руцінным. Тунель пункт-пункт дастаўляе пакет адзінаму партнёру на іншым канцы, таму копія дасягае роўна аднаго кліента. Масціраваны сегмент паводзіць сябе хутчэй як агульнае звяно, бо тунель нясе кадр, а мост вырашае, што заліваць. Гэта розныя мадэлі дастаўкі, і дызайн, які мяркуе другую, працуючы з першай, будзе выглядаць працоўным для аднаго атрымальніка і адмовіць для наступнага.

Для больш чым аднаго атрымальніка праз шматпунктавы сервер рэплікацыю трэба праектаваць яўна. Усталёўка маршруту multicast на шлюзе не вучыць VPN-сервер, якія партнёры павінны атрымаць копію, і ніякі маршрут на баку кліента не робіць гэтага рашэння за яго. Там, дзе патрабаванне — шмат атрымальнікаў, выкарыстоўвайце падтрыманую рэплікацыю або свядома выбраны альтэрнатыўны варыянт, і запішыце, які менавіта вы выбралі.

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