SSM per OpenVPN: vieno šaltinio ir grupės sekimas nuo pradžios iki pabaigos

Pasirinkite vieną srautą ir vieną gavėją, tada veskite tą porą per kiekvieną šuolį, o ne testuokite multicast kaip kategoriją. Šaltiniui būdingas sprendimas nepavyksta tiksliai vienoje iš keturių vietų: gavėjas niekada neprisijungė, maršrutizatorius atmetė paketą grįžtamajame kelyje, branduolys neturi būsenos, arba tunelis niekada nepristatė kopijos. Dirbant tokia tvarka kiekvienam šuoliui reikia kelių minučių, ir paaiškėja, kuri iš keturių iš tikrųjų yra.

Pirmiausia užfiksuokite šaltinį, grupę ir gavėją

Užsirašykite tris reikšmes prieš liesdami bet kurį įrenginį: siunčiančio šaltinio adresą, grupės adresą, prie kurio prisijungs gavėjas, ir potinklį, kuriame yra gavėjas. Iliustraciniam IPv4 srautui šaltinis 10.50.0.10 ir grupė 232.20.30.40 yra būtent ta pora, kuri tinka šaltiniui būdingam sprendimui. Viskas, kas neapibrėžčiau už šias tris reikšmes, negali būti testuojama.

Diapazonas 232/8 yra rezervuotas šaltiniui būdingam multicast, o modelis aprašytas RFC 4607 dokumente. Jei jūsų grupė yra už šio diapazono ribų, nors manote, kad vykdote SSM, sustokite ir patvirtinkite, ką diegimas iš tikrųjų turi omenyje, nes gavėjo prisijungimas ir maršrutizatoriaus persiuntimo sprendimas abu priklauso nuo modelio nuoseklumo.

Patikrinkite, ar gavėjas prisijungė prie šaltinio

Narystės ataskaita tik grupei nėra šaltiniui būdingas prisijungimas. Paklauskite gavėjo, kokio šaltinio jis prašė, ir pirmojo šuolio maršrutizatoriuje pažiūrėkite grupės būseną, ar atsiranda šaltinių sąrašas. Jei ataskaitoje nėra šaltinio, maršrutizatorius ją traktuos kaip prisijungimą prie bet kurio šaltinio, ir visas sprendimas tyliai suges į tai, ko neplanavote.

Linux gavėjoje patikrinkite, prie ko lizdas iš tikrųjų prenumeravo ir ką užfiksavo branduolys. Programos konfigūracijos failas nėra įrodymas; narystės lentelė yra įrodymas. Skaitykite ją, kol gavėjas iš tikrųjų veikia, nes įrašas gali trumpam likti po to, kai procesas, kuris jį sukūrė, baigiasi. Pasenęs įrašas iš ankstesnio bandymo yra patikimas klaidingo pasitikėjimo šaltinis.

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

Jei prisijungimas yra su laukiamu šaltiniu, pereikite prie maršrutizatorių. Jei jo nėra, jokia tunelio konfigūracija nepadės, nes nėra ko persiųsti.

Patikrinkite grįžtamąjį kelią prieš žiūrėdami į tunelį

Multicast maršrutizavimas atlieka grįžtamojo kelio patikrą, o paketas, atėjęs per sąsają, kuri skiriasi nuo tos, į kurią nurodo unicast maršrutas, išmetamas. Tai dažniausia priežastis, kodėl aiškiai siunčiamas srautas niekada nepasiekia kito šuolio, ir tai visiškai nesukuria naudingos programos lygio klaidos.

Maršrutizatoriuje, atsisukusiame į šaltinį, palyginkite maršrutą link šaltinio su sąsaja, per kurią paketai iš tikrųjų ateina. Maršrutizatoriuje, atsisukusiame į gavėją, padarykite tą patį gavėjo pačio potinkliui ir patvirtinkite, kad išeinančių sąsajų sąraše yra nuoroda į jį. Neatitikimas bet kuria kryptimi yra RPF gedimas, o ne narystės gedimas.

Tada patvirtinkite, kad šaltinio TTL yra pakankamai didelis išgyventi suprojektuotus maršrutizuotus šuolius. Srautas, kuris veikia pirmame maršrutizatoriuje ir miršta antrame, dažnai yra TTL klausimas, o ne politikos klausimas.

Skaitykite branduolio multicast būseną, o ne konfigūraciją

Konfigūracija pasako, ko prašėte; branduolys pasako, kas vyksta. Kiekviename Linux šuolyje skaitykite multicast maršrutizavimo įrašus ir patvirtinkite, kad tiksliai šaltinio ir grupės porai egzistuoja įeinančių ir išeinančių sąsajų sąrašas. Įrašas grupei su universalaus šaltinio reikšme yra kitas objektas, ir jis nepaaiškins šaltiniui būdingo srauto.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Maršrutizavimo daemonai laiko savo požiūrį virš šios būsenos, o ją spausdinanti komanda priklauso nuo to, kuri implementacija įdiegta. Principas pastovus: paklauskite daemono apie jo aukštupio įrašą porai, tada paklauskite branduolio, ar egzistuoja persiuntimo įrašas. Daemonas, kuris mano persiunčiantis, kai branduolys neturi įrašo, yra konfigūracijos aprėpties problema tame hoste.

Kai abu nesutaria, taisykite hostą, o ne VPN. Niekas žemiau negali kompensuoti šuolio, kuris nepersiunčia srauto, apie kurį klausėte. Užrašykite porą, įeinančią sąsają ir išeinantį sąrašą kiekvienam šuoliui, kol srautas veikia. Tas įrašas paverčia kitą gedimą palyginimu, o ne nauju tyrimu.

Nuspręskite, kaip tunelis iš tikrųjų replikuoja

Čia multicast per VPN nustoja būti rutina. Taškas-taškas tunelis pristato paketą vieninteliam gretutiniui kitame gale, todėl kopija pasiekia tiksliai vieną klientą. Tiltu sujungtas segmentas elgiasi labiau kaip bendrinė jungtis, nes tunelis neša kadrą, o tiltas nusprendžia, ką užtvindyti. Tai skirtingi pristatymo modeliai, ir sprendimas, kuris daro prielaidą apie antrąjį, vykdydamas pirmąjį, atrodys veikiantis vienam gavėjui ir suges kitam.

Kai daugiau nei vienas gavėjas per daugiataskį serverį, replikacija turi būti suprojektuota aiškiai. Multicast maršruto įdiegimas šliuze neišmoko VPN serverio, kurie gretutiniai turi gauti kopiją, ir joks kliento pusės maršrutas nepriima to sprendimo už jį. Kai reikalavimas yra daug gavėjų, naudokite palaikomą replikaciją arba sąmoningai pasirinktą alternatyvą, ir užsirašykite, kurią pasirinkote.

Galiausiai patikrinkite gavėjo pusėje siauru stebėjimu: tikslią šaltinį, grupę ir prievadą, laukiamoje sąsajoje, kol vienas įgaliotas gavėjas yra prisijungęs. SSM pasirenka siuntėją, ir pasirinkimas nėra to siuntėjo autentifikavimas, nei leidimas kitam multicast srautui kirsti tą pačią politiką.