SSM preko OpenVPN-a: praćenje jednog izvora i grupe od početka do kraja

Odaberite jedan tok i jednog primaoca, pa pratite taj par kroz svaki hop umjesto da multicast testirate kao kategoriju. Dizajn specifičan za izvor pada na tačno jednom od četiri mjesta: primalac se nikada nije pridružio, ruter je odbacio paket na povratnoj putanji, kernel nema stanje ili tunel nikada nije isporučio kopiju. Rad tim redom košta minute po hopu i kaže vam koje od ta četiri stvarno imate.

Prvo fiksirajte izvor, grupu i primaoca

Zapišite tri vrijednosti prije nego što dotaknete bilo koji uređaj: adresu izvora koji će slati, adresu grupe kojoj će se primalac pridružiti i podmrežu na kojoj primalac živi. Za ilustrativni IPv4 tok, izvor 10.50.0.10 i grupa 232.20.30.40 su upravo onaj par koji odgovara dizajnu specifičnom za izvor. Bilo šta neodređenije od te tri vrijednosti ne može se testirati.

Opseg 232/8 rezervisan je za multicast specifičan za izvor, a model je opisan u RFC 4607. Ako vaša grupa stoji izvan tog opsega dok mislite da pokrećete SSM, zaustavite se i potvrdite šta implementacija zaista namjerava, jer pridruživanje primaoca i odluka rutera o prosljeđivanju zavise od toga da model bude konzistentan.

Provjerite da se primalac pridružio izvoru

Izvještaj o članstvu samo za grupu nije pridruživanje specifično za izvor. Pitajte primaoca koji je izvor zatražio, a na ruteru prvog hopa pogledajte stanje grupe da vidite pojavljuje li se lista izvora. Ako izvještaj ne nosi izvor, ruter će ga tretirati kao pridruživanje bilo kojem izvoru i cijeli dizajn tiho degradira u nešto što niste planirali.

Na Linux primaocu provjerite na šta se socket stvarno pretplatilo i šta je kernel zabilježio. Konfiguracijska datoteka aplikacije nije dokaz; tabela članstva jeste. Čitajte je dok primalac stvarno radi, jer unos može kratko ostati nakon što proces koji ga je stvorio završi. Zastario unos iz ranijeg testa pouzdan je izvor lažne sigurnosti.

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

Ako je pridruživanje prisutno s očekivanim izvorom, pređite na rutere. Ako nedostaje, nikakva konfiguracija tunela neće pomoći, jer nema šta da se proslijedi.

Provjerite povratnu putanju prije nego što pogledate tunel

Multicast rutiranje obavlja provjeru povratne putanje, a paket koji stigne na interfejs različit od onog na koji pokazuje unicast ruta se odbacuje. To je najčešći razlog zašto tok koji se očito šalje nikada ne stigne do sljedećeg hopa i ne proizvodi nikakvu korisnu grešku na razini aplikacije.

Na ruteru okrenutom izvoru uporedite rutu prema izvoru s interfejsom na koji paketi stvarno stižu. Na ruteru okrenutom primaocu učinite isto za vlastitu podmrežu primaoca i potvrdite da lista odlaznih interfejsa uključuje link prema njoj. Neslaganje u bilo kojem smjeru je RPF kvar, a ne kvar članstva.

Zatim potvrdite da je TTL izvora dovoljno velik da preživi rutirane hopove koje ste projektovali. Tok koji radi na prvom ruteru i umire na drugom često je TTL pitanje, a ne pitanje politike.

Čitajte multicast stanje kernela, a ne konfiguraciju

Konfiguracija vam kaže šta ste tražili; kernel vam kaže šta se događa. Na svakom Linux hopu pročitajte multicast zapise rutiranja i potvrdite da lista ulaznih i odlaznih interfejsa postoji za tačan par izvor-grupa. Zapis za grupu sa zamjenskim izvorom drugi je objekat i neće objasniti tok specifičan za izvor.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Rutirajući demoni drže svoj pogled povrh tog stanja, a naredba koja ga ispisuje zavisi od toga koja je implementacija instalirana. Princip je stalan: pitajte demona za njegov upstream zapis za par, pa pitajte kernel postoji li zapis prosljeđivanja. Demon koji misli da prosljeđuje dok kernel nema zapis je problem u obimu konfiguracije na tom hostu.

Kada se njih dvoje ne slažu, popravite host, a ne VPN. Ništa nizvodno ne može nadoknaditi hop koji ne prosljeđuje tok o kojem ste pitali. Zabilježite par, ulazni interfejs i odlaznu listu za svaki hop dok tok radi. Taj zapis pretvara sljedeći kvar u poređenje umjesto u novu istragu.

Odlučite kako tunel stvarno replicira

Ovdje multicast preko VPN-a prestaje biti rutina. Tačka-na-tačku tunel isporučuje paket jedinom peeru na drugoj strani, pa kopija stiže tačno jednom klijentu. Premošteni segment ponaša se više kao dijeljeni link, jer tunel nosi okvir, a most odlučuje šta će preplaviti. To su različiti modeli isporuke, a dizajn koji pretpostavlja drugi dok radi prvi izgledat će ispravan za jednog primaoca i pasti za sljedećeg.

Za više od jednog primaoca preko višetačkastog servera replikacija se mora projektovati izričito. Instaliranje multicast rute na gateway ne uči VPN server koje peerove treba da dobiju kopiju, i nijedna ruta na strani klijenta ne donosi tu odluku umjesto njega. Gdje je zahtjev mnogo primalaca, koristite podržanu replikaciju ili namjerno odabranu alternativu i zapišite koju ste odabrali.

Konačno, provjerite na primaocu pod uskim posmatranjem: tačan izvor, grupa i port, na interfejsu koji očekujete, dok je pridružen jedan ovlašteni primalac. SSM bira pošiljaoca, a izbor nije autentifikacija tog pošiljaoca, niti dopuštenje drugom multicast saobraćaju da prođe istu politiku.