SSM pār OpenVPN: viena avota un grupas izsekošana no sākuma līdz beigām

Izvēlieties vienu straumi un vienu uztvērēju, pēc tam vediet šo pāri cauri katram lēcienam, nevis testējiet multicast kā kategoriju. Avotam raksturīgs dizains neizdodas tieši vienā no četrām vietām: uztvērējs nekad nav pievienojies, maršrutētājs noraidīja paketi atpakaļceļā, kodolam nav stāvokļa, vai tunelis nekad nav piegādājis kopiju. Strādājot šādā secībā, katrs lēciens prasa dažas minūtes, un kļūst skaidrs, kura no četrām patiešām ir.

Vispirms fiksējiet avotu, grupu un uztvērēju

Pierakstiet trīs vērtības, pirms pieskaraties jebkurai ierīcei: sūtošā avota adresi, grupas adresi, kurai pievienosies uztvērējs, un apakštīklu, kurā atrodas uztvērējs. Ilustratīvai IPv4 straumei avots 10.50.0.10 un grupa 232.20.30.40 ir tieši tas pāris, kas atbilst avotam raksturīgam dizainam. Viss neskaidrāks par šīm trim vērtībām nav testējams.

Diapazons 232/8 ir rezervēts avotam raksturīgam multicast, un modelis ir aprakstīts RFC 4607 dokumentā. Ja jūsu grupa atrodas ārpus šī diapazona, kamēr domājat, ka darbojat SSM, apstājieties un apstipriniet, ko ieviešana patiešām paredz, jo uztvērēja pievienošanās un maršrutētāja pārsūtīšanas lēmums abi ir atkarīgi no modeļa konsekvences.

Pārbaudiet, vai uztvērējs ir pievienojies avotam

Dalības ziņojums tikai grupai nav avotam raksturīga pievienošanās. Pajautājiet uztvērējam, kuru avotu tas pieprasīja, un pirmā lēciena maršrutētājā aplūkojiet grupas stāvokli, vai parādās avotu saraksts. Ja ziņojumā nav avota, maršrutētājs to uzskatīs par pievienošanos jebkuram avotam, un viss dizains klusi degradēsies kaut kādā, ko neplānojāt.

Linux uztvērējā pārbaudiet, kam ligzda patiešām abonējās un ko fiksēja kodols. Lietojumprogrammas konfigurācijas fails nav pierādījums; dalības tabula ir pierādījums. Lasiet to, kamēr uztvērējs patiešām darbojas, jo ieraksts var īsi palikt pēc tam, kad process, kas to izveidoja, ir beidzies. Novecojis ieraksts no iepriekšēja testa ir uzticams nepatiesa pārliecības avots.

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

Ja pievienošanās ar gaidīto avotu pastāv, pārejiet pie maršrutētājiem. Ja tās nav, nekāda tuneļa konfigurācija nepalīdzēs, jo nav ko pārsūtīt.

Pārbaudiet atpakaļceļu, pirms skatāties uz tuneli

Multicast maršrutēšana veic atpakaļceļa pārbaudi, un pakete, kas ierodas citā saskarnē nekā tajā, uz kuru norāda unicast maršruts, tiek izmesta. Tas ir visbiežākais iemesls, kāpēc straume, kas acīmredzami tiek sūtīta, nekad nesasniedz nākamo lēcienu, un tas nerada nekādu lietderīgu lietojumprogrammas līmeņa kļūdu.

Maršrutētājā, kas vērsts pret avotu, salīdziniet maršrutu uz avotu ar saskarni, kurā paketes patiešām ierodas. Maršrutētājā, kas vērsts pret uztvērēju, dariet to pašu ar uztvērēja paša apakštīklu un apstipriniet, ka izejošo saskarņu saraksts ietver saiti uz to. Neatbilstība jebkurā virzienā ir RPF kļūda, nevis dalības kļūda.

Pēc tam apstipriniet, ka avota TTL ir pietiekami liels, lai izturētu jūsu projektētos maršrutētos lēcienus. Straume, kas darbojas pirmajā maršrutētājā un mirst otrajā, bieži ir TTL jautājums, nevis politikas jautājums.

Lasiet kodola multicast stāvokli, nevis konfigurāciju

Konfigurācija pasaka, ko jūs pieprasījāt; kodols pasaka, kas notiek. Katrā Linux lēcienā lasiet multicast maršrutēšanas ierakstus un apstipriniet, ka precīzam avota un grupas pārim pastāv ienākošo un izejošo saskarņu saraksts. Ieraksts grupai ar universālu avotu ir cits objekts, un tas neizskaidros avotam raksturīgu plūsmu.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Maršrutēšanas dēmoni tur savu skatījumu virs šī stāvokļa, un to izdrukājošā komanda ir atkarīga no tā, kura implementācija ir instalēta. Princips ir nemainīgs: pajautājiet dēmonam tā augšupējas ierakstu pārim, pēc tam pajautājiet kodolam, vai pastāv pārsūtīšanas ieraksts. Dēmons, kas domā, ka pārsūta, kamēr kodolam nav ieraksta, ir konfigurācijas tvēruma problēma šajā resursdatorā.

Kad abi nesaskan, labojiet resursdatoru, nevis VPN. Nekas lejpus nevar kompensēt lēcienu, kas nepārsūta plūsmu, par kuru jūs jautājāt. Pierakstiet pāri, ienākošo saskarni un izejošo sarakstu katram lēcienam, kamēr straume darbojas. Šis ieraksts pārvērš nākamo kļūmi salīdzinājumā, nevis jaunā izmeklēšanā.

Izlemiet, kā tunelis patiešām repliķē

Šeit multicast pār VPN pārstāj būt rutīna. Punkts-punktam tunelis piegādā paketi vienīgajam partnerim otrā galā, tāpēc kopija sasniedz tieši vienu klientu. Tiltota segmenta uzvedība vairāk līdzinās koplietotai saitei, jo tunelis pārvadā kadru, un tilts izlemj, ko pārpludināt. Tie ir dažādi piegādes modeļi, un dizains, kas pieņem otro, kamēr darbojas pirmais, izskatīsies strādājošs vienam uztvērējam un neizdosies nākamajam.

Vairāk nekā vienam uztvērējam caur daudzpunktu serveri replikācija ir jāprojektē skaidri. Multicast maršruta instalēšana vārtejā neiemāca VPN serverim, kuri partneri saņems kopiju, un neviens klienta puses maršruts nepieņem šo lēmumu tā vietā. Kur prasība ir daudz uztvērēju, izmantojiet atbalstītu replikāciju vai apzināti izvēlētu alternatīvu, un pierakstiet, kuru izvēlējāties.

Visbeidzot, pārbaudiet uztvērējā šaurā novērojumā: precīzu avotu, grupu un portu, gaidītajā saskarnē, kamēr viens autorizēts uztvērējs ir pievienojies. SSM izvēlas sūtītāju, un izvēle nav šī sūtītāja autentifikācija, nedz atļauja citam multicast trafikam šķērsot to pašu politiku.