SSM prin OpenVPN: urmărirea unei surse și a unui grup de la început până la sfârșit

Alegeți un flux și un receptor, apoi urmăriți acea pereche prin fiecare salt în loc să testați multicast ca o categorie. Un design specific sursei eșuează exact într-unul din patru locuri: receptorul nu s-a alăturat niciodată, routerul a respins pachetul pe calea de întoarcere, nucleul nu are stare sau tunelul nu a livrat niciodată o copie. Lucrul în această ordine costă minute pe salt și vă spune care dintre cele patru îl aveți de fapt.

Fixați mai întâi sursa, grupul și receptorul

Notați trei valori înainte de a atinge orice dispozitiv: adresa sursei care va trimite, adresa grupului la care se va alătura receptorul și subrețeaua în care se află receptorul. Pentru un flux IPv4 ilustrativ, o sursă 10.50.0.10 și un grup 232.20.30.40 sunt genul de pereche care se potrivește unui design specific sursei. Orice mai vag decât aceste trei valori nu poate fi testat.

Intervalul 232/8 este rezervat pentru multicast specific sursei, iar modelul este descris în RFC 4607. Dacă grupul dumneavoastră se află în afara acelui interval în timp ce credeți că rulați SSM, opriți-vă și confirmați ce intenționează de fapt implementarea, pentru că alăturarea receptorului și decizia de forwarding a routerului depind ambele de consistența modelului.

Verificați că receptorul s-a alăturat sursei

Un raport de apartenență doar pentru grup nu este o alăturare specifică sursei. Întrebați receptorul ce sursă a cerut, iar pe routerul primului salt priviți starea grupului pentru a vedea dacă apare o listă de surse. Dacă raportul nu poartă nicio sursă, routerul îl va trata ca o alăturare de la orice sursă, iar întregul design degenerează în tăcere în ceva ce nu ați planificat.

Pe un receptor Linux, verificați la ce s-a abonat de fapt socketul și ce a înregistrat nucleul. Fișierul de configurare al aplicației nu este o dovadă; tabelul de apartenență este. Citiți-l în timp ce receptorul rulează efectiv, pentru că o intrare poate persista scurt după ce procesul care a creat-o iese. O intrare veche dintr-un test anterior este o sursă sigură de încredere falsă.

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

Dacă alăturarea este prezentă cu sursa așteptată, treceți la routere. Dacă lipsește, nicio configurație de tunel nu va ajuta, pentru că nu există nimic de forwardat.

Verificați calea de întoarcere înainte de a vă uita la tunel

Rutarea multicast efectuează o verificare a căii de întoarcere, iar un pachet care sosește pe o interfață diferită de cea către care indică ruta unicast este eliminat. Acesta este cel mai frecvent motiv pentru care un flux care este evident trimis nu ajunge niciodată la următorul salt și nu produce nicio eroare utilă la nivel de aplicație.

Pe routerul orientat spre sursă, comparați ruta spre sursă cu interfața pe care sosesc efectiv pachetele. Pe routerul orientat spre receptor, faceți același lucru pentru subrețeaua proprie a receptorului și confirmați că lista interfețelor de ieșire include legătura către ea. O nepotrivire în orice direcție este o defecțiune RPF, nu o defecțiune de apartenență.

Apoi confirmați că TTL-ul sursei este suficient de mare pentru a supraviețui salturilor rutate pe care le-ați proiectat. Un flux care funcționează pe primul router și moare pe al doilea este adesea o chestiune de TTL, nu de politică.

Citiți starea multicast a nucleului în loc de configurație

Configurația vă spune ce ați cerut; nucleul vă spune ce se întâmplă. Pe fiecare salt Linux, citiți intrările de rutare multicast și confirmați că există o listă de interfețe de intrare și de ieșire pentru perechea exactă de sursă și grup. O intrare pentru grup cu o sursă wildcard este un obiect diferit și nu va explica un flux specific sursei.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Daemonii de rutare își păstrează propria vedere deasupra acelei stări, iar comanda care o afișează depinde de implementarea instalată. Principiul este constant: întrebați daemonul despre intrarea sa amonte pentru pereche, apoi întrebați nucleul dacă există o intrare de forwarding. Un daemon care crede că face forwarding în timp ce nucleul nu are nicio intrare este o problemă de sferă a configurației pe acel host.

Când cele două nu sunt de acord, reparați hostul și nu VPN-ul. Nimic în aval nu poate compensa un salt care nu forwardează fluxul despre care ați întrebat. Notați perechea, interfața de intrare și lista de ieșire pentru fiecare salt cât timp fluxul funcționează. Acea înregistrare transformă următoarea defecțiune într-o comparație în loc de o anchetă nouă.

Decideți cum replică de fapt tunelul

Aici multicastul peste un VPN încetează să mai fie rutină. Un tunel punct-la-punct livrează un pachet singurului peer de la celălalt capăt, așa că o copie ajunge exact la un client. Un segment cu punte se comportă mai mult ca o legătură partajată, pentru că tunelul transportă cadrul, iar puntea decide ce să inunde. Sunt modele de livrare diferite, iar un design care presupune al doilea în timp ce rulează primul va părea că funcționează pentru un receptor și va eșua pentru următorul.

Pentru mai mult de un receptor printr-un server multipunct, replicarea trebuie proiectată explicit. Instalarea unei rute multicast pe gateway nu învață serverul VPN care peeri trebuie să primească o copie, iar nicio rută din partea clientului nu ia acea decizie în locul lui. Unde cerința este mulți receptori, folosiți replicare acceptată sau o alternativă aleasă deliberat și notați pe care ați ales-o.

În final, verificați la receptor cu o observație îngustă: sursa, grupul și portul exacte, pe interfața la care vă așteptați, în timp ce un receptor autorizat este alăturat. SSM selectează un expeditor, iar selecția nu este o autentificare a acelui expeditor, nici o permisiune pentru alt trafic multicast de a traversa aceeași politică.