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

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

Prvo fiksirajte izvor, grupu i primatelja

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

Raspon 232/8 rezerviran je za multicast specifičan za izvor, a model je opisan u RFC 4607. Ako vaša grupa stoji izvan tog raspona dok mislite da pokrećete SSM, zaustavite se i potvrdite što implementacija zaista namjerava, jer pridruživanje primatelja i odluka usmjerivača o prosljeđivanju ovise oboje o tome da model bude konzistentan.

Provjerite da se primatelj pridružio izvoru

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

Na Linux primatelju provjerite na što se socket stvarno pretplatio i što je kernel zabilježio. Konfiguracijska datoteka aplikacije nije dokaz; tablica članstva jest. Čitajte je dok primatelj 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, prijeđite na usmjerivače. Ako nedostaje, nikakva konfiguracija tunela neće pomoći, jer nema što proslijediti.

Provjerite povratnu putanju prije nego što pogledate tunel

Multicast usmjeravanje obavlja provjeru povratne putanje, a paket koji stigne na sučelje različito od onoga na koje pokazuje unicast ruta odbacuje se. To je najčešći razlog zašto tok koji se očito šalje nikada ne stigne do sljedećeg skoka i ne proizvodi nikakvu korisnu pogrešku na razini aplikacije.

Na usmjerivaču okrenutom izvoru usporedite rutu prema izvoru sa sučeljem na koje paketi stvarno stižu. Na usmjerivaču okrenutom primatelju učinite isto za vlastitu podmrežu primatelja i potvrdite da popis odlaznih sučelja uključuje vezu 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 usmjerene skokove koje ste projektirali. Tok koji radi na prvom usmjerivaču i umire na drugom često je TTL pitanje, a ne pitanje politike.

Čitajte multicast stanje kernela, a ne konfiguraciju

Konfiguracija vam kaže što ste tražili; kernel vam kaže što se događa. Na svakom Linux skoku pročitajte multicast zapise usmjeravanja i potvrdite da popis ulaznih i odlaznih sučelja postoji za točan par izvor-grupa. Zapis za grupu sa zamjenskim izvorom drugi je objekt 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

Usmjerivački daemoni drže svoj pogled povrh tog stanja, a naredba koja ga ispisuje ovisi o tome koja je implementacija instalirana. Princip je stalan: pitajte daemona za njegov upstream zapis za par, pa pitajte kernel postoji li zapis prosljeđivanja. Daemon koji misli da prosljeđuje dok kernel nema zapis jest problem opsega konfiguracije na tom hostu.

Kada se njih dvoje ne slažu, popravite host, a ne VPN. Ništa nizvodno ne može nadoknaditi skok koji ne prosljeđuje tok o kojem ste pitali. Zabilježite par, ulazno sučelje i odlazni popis za svaki skok dok tok radi. Taj zapis pretvara sljedeći kvar u usporedbu umjesto u novu istragu.

Odlučite kako tunel stvarno replicira

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

Za više od jednog primatelja preko višetočkastog poslužitelja replikacija se mora projektirati izričito. Instaliranje multicast rute na gateway ne uči VPN poslužitelj koji peerovi trebaju dobiti kopiju, i nijedna ruta na strani klijenta ne donosi tu odluku umjesto njega. Gdje je zahtjev mnogo primatelja, koristite podržanu replikaciju ili namjerno odabranu alternativu i zapišite koju ste odabrali.

Konačno, provjerite na primatelju pod uskim promatranjem: točan izvor, grupa i port, na sučelju koje očekujete, dok je pridružen jedan ovlašteni primatelj. SSM bira pošiljatelja, a izbor nije autentifikacija tog pošiljatelja, niti dopuštenje drugom multicast prometu da prođe istu politiku.