SSM oor OpenVPN: een bron en groep van begin tot einde volg

Kies een stroom en een ontvanger en volg daardie paar deur elke hop, eerder as om multicast as ’n kategorie te toets. ’n Bron-spesifieke ontwerp faal op presies een van vier plekke: die ontvanger het nooit aangesluit nie, die roeteerder het die pakket op sy terugpad verwerp, die kernel het geen toestand nie, of die tonnel het nooit ’n kopie afgelewer nie. Om in daardie volgorde te werk kos minute per hop en sê vir jou watter van die vier jy werklik het.

Bepaal eers die bron, groep en ontvanger

Skryf drie waardes neer voordat jy enige toestel aanraak: die bronadres wat gaan stuur, die groepadres waarby die ontvanger gaan aansluit, en die subnet waarop die ontvanger woon. Vir ’n illustratiewe IPv4-stroom is ’n bron van 10.50.0.10 en ’n groep van 232.20.30.40 die soort paar wat by ’n bron-spesifieke ontwerp pas. Enigiets vager as daardie drie waardes kan nie getoets word nie.

Die reeks 232/8 is vir bron-spesifieke multicast gereserveer, en die model word beskryf in RFC 4607. As jou groep buite daardie reeks lê terwyl jy glo jy bedryf SSM, stop en bevestig wat die ontplooiing werklik bedoel, want die ontvanger se aansluiting en die roeteerder se besluit oor aanstuur hang albei daarvan af dat die model konsekwent is.

Kontroleer dat die ontvanger by die bron aangesluit het

’n Lidmaatskapverslag vir die groep alleen is nie ’n bron-spesifieke aansluiting nie. Vra die ontvanger watter bron dit aangevra het, en kyk op die eerste-hop-roeteerder na die groeptoestand om te sien of ’n bronlys verskyn. As die verslag geen bron dra nie, sal die roeteerder dit as ’n aansluiting van enige bron behandel, en die hele ontwerp sal stilweg ontaard in iets wat jy nie beplan het nie.

Kontroleer op ’n Linux-ontvanger waarop die sok werklik ingeteken het en wat die kernel aangeteken het. Die toepassing se konfigurasielêer is nie bewyse nie; die lidmaatskapstabel is. Lees dit terwyl die ontvanger werklik loop, want ’n inskrywing kan kort ná die proses wat dit geskep het, verdwyn. ’n Verouderde inskrywing uit ’n vroeëre toets is ’n betroubare bron van valse selfvertroue.

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

As die aansluiting daar is met die verwagte bron, beweeg na die roeteerders. As dit ontbreek, sal geen hoeveelheid tonnelkonfigurasie help nie, want daar is niks om aan te stuur nie.

Verifieer die terugpad voordat jy na die tonnel kyk

Multicast-roetering doen ’n terugpadkontrole, en ’n pakket wat op ’n ander koppelvlak aankom as die een waarheen die unicast-roete wys, word laat val. Dit is die algemeenste rede waarom ’n stroom wat duidelik gestuur word nooit die volgende hop bereik nie, en dit lewer hoegenaamd geen nuttige toepassingsvlak-fout nie.

Vergelyk op die roeteerder wat na die bron kyk die roete na die bron met die koppelvlak waarop die pakkette werklik aankom. Doen dieselfde op die roeteerder wat na die ontvanger kyk vir die ontvanger se eie subnet en bevestig dat die uitgaande koppelvlaklys die skakel daarheen insluit. ’n Wanverhouding in enige rigting is ’n RPF-fout, nie ’n lidmaatskapfout nie.

Bevestig dan dat die bron se TTL groot genoeg is om die gerouteerde hope te oorleef wat jy ontwerp het. ’n Stroom wat op die eerste roeteerder werk en by die tweede sterf, is dikwels ’n TTL-vraag eerder as ’n beleidsvraag.

Lees die kernel se multicast-toestand eerder as die konfigurasie

Konfigurasie vertel jou wat jy gevra het; die kernel vertel jou wat gebeur. Lees op elke Linux-hop die multicast-roeteringinskrywings en bevestig dat daar ’n inkomende en uitgaande koppelvlaklys vir die presiese bron-en-groep-paar bestaan. ’n Inskrywing vir die groep met ’n wildcard-bron is ’n ander objek, en dit sal nie ’n bron-spesifieke vloei verklaar nie.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Roeteringsdaemons hou hul eie siening bo-op daardie toestand, en die opdrag wat dit druk hang af van watter implementering geïnstalleer is. Die beginsel is konstant: vra die daemon vir sy opstroom-inskrywing vir die paar, vra dan die kernel of ’n aanstuurinskrywing bestaan. ’n Daemon wat dink hy stuur aan terwyl die kernel geen inskrywing het nie, is ’n probleem met die omvang van die konfigurasie op daardie gasheer.

Wanneer die twee verskil, maak die gasheer reg eerder as die VPN. Niks stroomaf kan vergoed vir ’n hop wat nie die vloei aanstuur wat jy gevra het nie. Teken die paar, die inkomende koppelvlak en die uitgaande lys vir elke hop aan terwyl die stroom werk. Daardie rekord maak die volgende fout ’n vergelyking in plaas van ’n nuwe ondersoek.

Besluit hoe die tonnel werklik repliseer

Dit is waar multicast oor ’n VPN ophou roetine wees. ’n Punt-tot-punt-tonnel lewer ’n pakket by die enkele eweknie aan die ander kant, so ’n kopie bereik presies een kliënt. ’n Oorbrugde segment gedra hom meer soos ’n gedeelde skakel, want die tonnel dra die raam en die brug besluit wat om te oorstroom. Dit is verskillende afleweringsmodelle, en ’n ontwerp wat die tweede aanneem terwyl hy die eerste bedryf, sal vir een ontvanger werk en vir die volgende faal.

Vir meer as een ontvanger oor ’n multipunt-bediener moet replisering eksplisiet ontwerp word. Om ’n multicast-roete op die poort te installeer leer nie die VPN-bediener watter eweknieë ’n kopie moet kry nie, en geen kliëntkant-roete maak daardie besluit vir hom nie. Waar die vereiste baie ontvangers is, gebruik ondersteunde replisering of ’n doelbewus gekose alternatief, en skryf neer watter een jy gekies het.

Verifieer laastens by die ontvanger onder ’n nou waarneming: die presiese bron, groep en poort, op die koppelvlak wat jy verwag, terwyl een gemagtigde ontvanger aangesluit is. SSM kies ’n sender, en keuse is nie verifikasie van daardie sender nie, ook nie toestemming vir ander multicast-verkeer om dieselfde beleid te kruis nie.