SSM prek OpenVPN: sledenje enemu viru in skupini od začetka do konca

Izberite en tok in enega prejemnika, nato pa to dvojico peljite skozi vsak skok, namesto da bi multicast testirali kot kategorijo. Zasnova, specifična za vir, odpove natanko na enem od štirih mest: prejemnik se ni nikoli pridružil, usmerjevalnik je paket na povratni poti zavrnil, jedro nima stanja ali tunel ni nikoli dostavil kopije. Delo v tem vrstnem redu stane nekaj minut na skok in vam pove, kateri od štirih primerov je v resnici vaš.

Najprej določite vir, skupino in prejemnika

Zapišite tri vrednosti, preden se dotaknete katere koli naprave: naslov vira, ki bo pošiljal, naslov skupine, ki se ji bo prejemnik pridružil, in podomrežje, v katerem prejemnik živi. Za ilustrativen tok IPv4 sta vir 10.50.0.10 in skupina 232.20.30.40 ravno tisti par, ki ustreza zasnovi, specifični za vir. Česar koli manj določenega od teh treh vrednosti ni mogoče preizkusiti.

Razpon 232/8 je rezerviran za multicast, specifičen za vir, model pa je opisan v RFC 4607. Če je vaša skupina zunaj tega razpona, medtem ko menite, da izvajate SSM, se ustavite in potrdite, kaj namerava uvajanje v resnici, ker sta pridružitev prejemnika in odločitev usmerjevalnika o posredovanju odvisni od tega, da je model dosleden.

Preverite, ali se je prejemnik pridružil viru

Poročilo o članstvu samo za skupino ni pridružitev, specifična za vir. Vprašajte prejemnika, kateri vir je zahteval, in na usmerjevalniku prvega skoka poglejte stanje skupine, ali se pojavi seznam virov. Če poročilo ne nosi vira, bo usmerjevalnik z njim ravnal kot s pridružitvijo kateremu koli viru in celotna zasnova se tiho degenerira v nekaj, česar niste načrtovali.

Na prejemniku Linux preverite, na kaj se je vtičnica dejansko naročila in kaj je jedro zabeležilo. Konfiguracijska datoteka aplikacije ni dokaz; tabela članstva je dokaz. Berite jo, medtem ko prejemnik resnično deluje, ker lahko vnos po izhodu procesa, ki ga je ustvaril, ostane še kratek čas. Zastarel vnos iz prejšnjega testa je zanesljiv vir lažnega zaupanja.

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

Če je pridružitev prisotna s pričakovanim virom, pojdite na usmerjevalnike. Če je ni, nobena konfiguracija tunela ne bo pomagala, ker ni ničesar za posredovanje.

Preverite povratno pot, preden pogledate tunel

Usmerjanje multicast izvede preverjanje povratne poti, paket, ki prispe na vmesnik, ki ni tisti, na katerega kaže usmeritev unicast, pa se zavrže. To je najpogostejši razlog, da tok, ki je očitno poslan, nikoli ne doseže naslednjega skoka, in pri tem ne nastane nobena koristna napaka na ravni aplikacije.

Na usmerjevalniku, obrnjenem proti viru, primerjajte pot do vira z vmesnikom, na katerem paketi resnično prispejo. Na usmerjevalniku, obrnjenem proti prejemniku, storite enako za lastno podomrežje prejemnika in potrdite, da seznam odhodnih vmesnikov vključuje povezavo do njega. Neskladje v katero koli smer je okvara RPF, ne okvara članstva.

Nato potrdite, da je TTL vira dovolj velik, da preživi načrtovane usmerjene skoke. Tok, ki deluje na prvem usmerjevalniku in umre na drugem, je pogosto vprašanje TTL in ne politike.

Berite stanje multicast jedra namesto konfiguracije

Konfiguracija vam pove, kaj ste zahtevali; jedro vam pove, kaj se dogaja. Na vsakem skoku Linux preberite vnose usmerjanja multicast in potrdite, da za natančen par vira in skupine obstaja seznam vhodnih in izhodnih vmesnikov. Vnos za skupino s splošnim virom je drug objekt in toka, specifičnega za vir, ne bo pojasnil.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Usmerjevalni demoni držijo svoj pogled nad tem stanjem, ukaz, ki ga izpiše, pa je odvisen od tega, katera izvedba je nameščena. Načelo je stalno: demona vprašajte za njegov nadrejeni vnos za par, nato jedro vprašajte, ali vnos posredovanja obstaja. Demon, ki misli, da posreduje, medtem ko jedro nima vnosa, je težava obsega konfiguracije na tem gostitelju.

Ko se oba ne ujemata, popravite gostitelja in ne VPN. Nič dolvodno ne more nadomestiti skoka, ki ne posreduje toka, po katerem ste spraševali. Zapisujte par, vhodni vmesnik in odhodni seznam za vsak skok, dokler tok deluje. Ta zapis spremeni naslednjo okvaro v primerjavo namesto nove preiskave.

Odločite, kako tunel v resnici replicira

Tu multicast prek VPN preneha biti rutina. Tunel od točke do točke dostavi paket edinemu partnerju na drugi strani, zato kopija doseže natanko enega odjemalca. Premoščen segment se obnaša bolj kot deljena povezava, ker tunel nosi okvir, most pa odloči, kaj poplavi. To sta različna modela dostave in zasnova, ki predvideva drugega, medtem ko izvaja prvega, bo za enega prejemnika delovala, za naslednjega pa ne.

Za več kot enega prejemnika prek večtočkovnega strežnika je treba replikacijo načrtovati izrecno. Namestitev poti multicast na prehodu ne nauči strežnika VPN, kateri partnerski vozli naj prejmejo kopijo, in nobena pot na strani odjemalca te odločitve ne sprejme namesto njega. Kjer je zahteva veliko prejemnikov, uporabite podprto replikacijo ali namerno izbrano alternativo in zapišite, katero ste izbrali.

Nazadnje preverite pri prejemniku z ozkim opazovanjem: natančen vir, skupino in vrata, na vmesniku, ki ga pričakujete, medtem ko je pridružen en pooblaščen prejemnik. SSM izbere pošiljatelja, izbira pa ni preverjanje istovetnosti tega pošiljatelja niti dovoljenje, da bi drug promet multicast prečkal isto politiko.