SSM yfir OpenVPN: fylgja einni upptök og hópi frá byrjun til enda

Veldu einn straum og einn viðtakanda og fylgdu því pari í gegnum hvert stökk í stað þess að prófa multicast sem flokk. Upptökusértæk hönnun bregst á nákvæmlega einum af fjórum stöðum: viðtakandinn gekk aldrei inn, beinin hafnaði pakkanum á bakleið sinni, kjarninn hefur ekkert ástand, eða göngin afhentu aldrei afrit. Að vinna í þeirri röð kostar mínútur á hvert stökk og segir þér hverra fjögurra þú hefur í raun.

Festu fyrst upptökina, hópinn og viðtakandann

Skrifaðu niður þrjú gildi áður en þú snertir nokkurt tæki: heimilisfang upptakarins sem mun senda, heimilisfang hópsins sem viðtakandinn mun ganga í og undirnetið sem viðtakandinn er á. Fyrir dæmigerðan IPv4 straum eru upptök 10.50.0.10 og hópur 232.20.30.40 einmitt þannig par sem hentar upptökusértækri hönnun. Eitthvað óljósara en þessi þrjú gildi er ekki hægt að prófa.

Sviðið 232/8 er frátekið fyrir upptökusértækt multicast og líkaninu er lýst í RFC 4607. Ef hópurinn þinn er utan þess sviðs á meðan þú heldur að þú sért að keyra SSM, stöðvaðu og staðfestu hvað uppsetningin ætlar sér í raun, því aðild viðtakandans og framsendingarákvörðun beinisins eru bæði háð því að líkanið sé samkvæmt.

Athugaðu að viðtakandinn hafi gengið í upptökina

Aðildarskýrsla fyrir hópinn eina og sér er ekki upptökusértæk aðild. Spurðu viðtakandann hvaða upptök hann bað um og á beini fyrsta stökksins skoðaðu stöðu hópsins til að sjá hvort listi yfir upptök birtist. Ef skýrslan ber engar upptök mun beinin meðhöndla hana sem aðild að hvaða upptökum sem er og öll hönnunin hrörnar hljóðlaust í eitthvað sem þú skipulagðir ekki.

Á Linux-viðtakanda skaltu athuga við hvað sálin skráði sig í raun og hvað kjarninn skráði. Stillingarskrá forritsins er ekki sönnun; aðildartaflan er það. Lestu hana á meðan viðtakandinn er í raun að keyra, því færsla getur varað stutta stund eftir að ferlið sem bjó hana til hættir. Úrelt færsla úr fyrri prófun er áreiðanleg uppspretta falsks öryggis.

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

Ef aðildin er til staðar með væntum upptökum skaltu fara yfir á beinana. Ef hún vantar mun engin göngustilling hjálpa, því ekkert er til að senda áfram.

Staðfestu bakleiðina áður en þú lítur á göngin

Multicast-beining framkvæmir bakleiðarathugun og pakki sem kemur inn á öðru tengi en því sem unicast-leiðin bendir á er látinn falla. Þetta er algengasta ástæðan fyrir því að straumur sem greinilega er sendur nær aldrei næsta stökki, og það myndar enga nytsama villu á forritastigi.

Á beininum sem snýr að upptökunum skaltu bera saman leiðina að upptökunum við tengið sem pakkarnir koma í raun inn á. Á beininum sem snýr að viðtakandanum skaltu gera það sama fyrir eigið undirnet viðtakandans og staðfesta að listinn yfir útleiðir innihaldi hlekkinn að því. Ósamræmi í hvora átt sem er er RPF-bilun, ekki aðildarbilun.

Staðfestu svo að TTL upptakarins sé nógu stórt til að lifa af þau beinu stökk sem þú hannaðir. Straumur sem virkar á fyrsta beininum og deyr á því öðru er oft TTL-spurning frekar en stefnumótun.

Lestu multicast-ástand kjarnans frekar en stillinguna

Stillingin segir þér hvað þú baðst um; kjarninn segir þér hvað er að gerast. Á hverju Linux-stökki skaltu lesa multicast-beiningarfærslurnar og staðfesta að listi yfir inn- og útleiðir sé til fyrir nákvæma parið upptök og hópur. Færsla fyrir hópinn með algildum upptökum er annar hlutur og mun ekki útskýra upptökusértækan straum.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Beiningardæmonar halda eigin sýn ofan á því ástandi og skipunin sem prentar hana fer eftir því hvaða útfærsla er uppsett. Meginreglan er stöðug: spurðu dæmoninn um uppstraumsfærslu sína fyrir parið og spurðu svo kjarnann hvort sendingarfærsla sé til. Dæmon sem heldur að hann sendi áfram á meðan kjarninn hefur enga færslu er stillingarumfangs vandamál á þeim vélum.

Þegar þau tvenn eru ósammála skaltu laga vélina en ekki VPN-ið. Ekkert niðri getur bætt fyrir stökk sem sendir ekki áfram strauminn sem þú spurðir um. Skráðu parið, innleiðina og útlistann fyrir hvert stökk á meðan straumurinn virkar. Sú skráning gerir næstu bilun að samanburði í stað nýrrar rannsóknar.

Ákveddu hvernig göngin fjölfalda í raun

Hér hættir multicast yfir VPN að vera rútína. Punkt-til-punkt göng skila pakka til eina jafningjans hinum megin, svo afrit nær nákvæmlega einum skjáseti. Brúað svið hagar sér frekar eins og deilt hlekkur, því göngin bera rammann og brúin ákveður hvað skal flæða yfir. Þetta eru ólík afhendingarlíkön og hönnun sem gerir ráð fyrir því seinni á meðan hún keyrir það fyrra mun virðast virka fyrir einn viðtakanda og bregðast fyrir þann næsta.

Fyrir fleiri en einn viðtakanda yfir fjölpunktaþjón skal fjölföldun hönnuð skýrt. Að setja multicast-leið á gáttina kennir VPN-þjóninum ekki hvaða jafningjar eigi að fá afrit og engin leið á biðlarahlið tekur þá ákvörðun fyrir hana. Þar sem krafan er margir viðtakendur skaltu nota studda fjölföldun eða vísvitandi valinn valkost og skrifa niður hvorn þú valdir.

Að lokum skaltu staðfesta hjá viðtakandanum við þrönga athugun: nákvæm upptök, hópur og port á því tengi sem þú átt von á, á meðan einn heimilaður viðtakandi er inni. SSM velur sendanda og valið er ekki auðkenning þess sendanda, né leyfi fyrir annan multicast-umferð að fara yfir sömu stefnu.