SSM super OpenVPN: sekvi unu fonton kaj grupon de komenco ĝis fino

Elektu unu fluon kaj unu ricevanton, poste sekvu tiun paron tra ĉiu salto anstataŭ testi multicast kiel kategorion. Font-specifa dezajno malsukcesas ĝuste ĉe unu el kvar lokoj: la ricevanto neniam aliĝis, la enkursigilo rifuzis la paketon sur ĝia revena vojo, la kerno havas neniun staton, aŭ la tunelo neniam liveris kopion. Labori en tiu ordo kostas minutojn por salto kaj diras al vi kiun el la kvar vi vere havas.

Unue fiksu la fonton, la grupon kaj la ricevanton

Notu tri valorojn antaŭ ol tuŝi ajnan aparaton: la fontadreson kiu sendos, la grupadreson al kiu la ricevanto aliĝos, kaj la subreton kie la ricevanto loĝas. Por ilustra IPv4-fluo, fonto 10.50.0.10 kaj grupo 232.20.30.40 estas ĝuste tiu speco de paro kiu taŭgas por font-specifa dezajno. Io ajn pli malklara ol tiuj tri valoroj ne povas esti testata.

La intervalo 232/8 estas rezervita por font-specifa multicast, kaj la modelo estas priskribita en RFC 4607. Se via grupo troviĝas ekster tiu intervalo dum vi kredas ke vi funkciigas SSM, haltu kaj konfirmu kion la enkonduko efektive celas, ĉar la aliĝo de la ricevanto kaj la plusenda decido de la enkursigilo ambaŭ dependas de tio ke la modelo estu konsekvenca.

Kontrolu ke la ricevanto aliĝis al la fonto

Membreca raporto nur por la grupo ne estas font-specifa aliĝo. Demandu la ricevanton kiun fonton ĝi petis, kaj sur la unua-salta enkursigilo rigardu la grupan staton por vidi ĉu aperas fontlisto. Se la raporto portas neniun fonton, la enkursigilo traktos ĝin kiel aliĝon de iu ajn fonto kaj la tuta dezajno silente degeneros en ion, kion vi ne planis.

Sur Linux-ricevanto, kontrolu al kio la ingo efektive abonis kaj kion la kerno registris. La agorda dosiero de la aplikaĵo ne estas pruvo; la membrectabelo estas. Legu ĝin dum la ricevanto efektive funkcias, ĉar rikordo povas resti mallonge post kiam la procezo, kiu kreis ĝin, finiĝis. Malnovega rikordo el pli frua testo estas fidinda fonto de falsa memfido.

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

Se la aliĝo ĉeestas kun la atendata fonto, moviĝu al la enkursigiloj. Se ĝi mankas, nenia tunela agordo helpos, ĉar estas nenio plusenda.

Kontrolu la revenan vojon antaŭ ol rigardi la tunelon

Multicast-enkursigado faras kontrolon de la revena vojo, kaj paketo kiu alvenas sur interfaco malsama ol tiu, kiun indikas la unicast-vojo, estas forĵetata. Tio estas la plej ofta kialo, ke fluo kiu videble estas sendata neniam atingas la sekvan salton, kaj ĝi produktas tute neniun utilan eraron je aplikaĵa nivelo.

Sur la enkursigilo turnita al la fonto, komparu la vojon al la fonto kun la interfaco sur kiu la paketoj efektive alvenas. Sur la enkursigilo turnita al la ricevanto, faru la samon por la propra subreto de la ricevanto kaj konfirmu ke la listo de elirantaj interfacoj inkluzivas la ligilon al ĝi. Miskongruo en iu ajn direkto estas RPF-malsukceso, ne membreca malsukceso.

Poste konfirmu ke la TTL de la fonto estas sufiĉe granda por postvivi la enkursigitajn saltojn, kiujn vi projektis. Fluo kiu funkcias sur la unua enkursigilo kaj mortas sur la dua estas ofte TTL-demando, ne politika demando.

Legu la multicast-staton de la kerno anstataŭ la agordon

Agordo diras al vi kion vi petis; la kerno diras al vi kio okazas. Sur ĉiu Linux-salto, legu la multicast-enkursigajn rikordojn kaj konfirmu ke listo de enirantaj kaj elirantaj interfacoj ekzistas por la ekzakta paro de fonto kaj grupo. Rikordo por la grupo kun ĵokera fonto estas alia objekto, kaj ĝi ne klarigos font-specifan fluon.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Enkursigaj demonoj tenas sian propran vidon super tiu stato, kaj la komando, kiu presas ĝin, dependas de tio, kiu efektivigo estas instalita. La principo estas konstanta: demandu la demonon pri ĝia alfluanta rikordo por la paro, poste demandu la kernon ĉu ekzistas plusenda rikordo. Demono kiu pensas ke ĝi plusendas dum la kerno havas neniun rikordon estas agorda ampleksa problemo sur tiu gastiganto.

Kiam la du malkongruas, ripari la gastiganton anstataŭ la VPN-on. Nenio malsupra povas kompensi salton, kiu ne plusendas la fluon pri kiu vi demandis. Registru la paron, la enirantan interfacon kaj la eliran liston por ĉiu salto dum la fluo funkcias. Tiu registro igas la sekvan malsukceson komparo anstataŭ nova esploro.

Decidu kiel la tunelo efektive reproduktas

Ĉi tie multicast super VPN ĉesas esti rutino. Punkto-al-punkta tunelo liveras paketon al la sola samtavolano ĉe la alia fino, do kopio atingas ekzakte unu klienton. Pontigita segmento kondutas pli kiel komuna ligilo, ĉar la tunelo portas la kadron kaj la ponto decidas kion inundigi. Tiuj estas malsamaj transdonaj modeloj, kaj dezajno kiu supozas la duan dum ĝi funkciigas la unuan ŝajnos funkcii por unu ricevanto kaj malsukcesos por la sekva.

Por pli ol unu ricevanto tra plurpunkta servilo, la reproduktado devas esti projektita eksplicite. Instali multicast-vojon sur la pordego ne instruas al la VPN-servilo kiuj samtavolanoj devus ricevi kopion, kaj nenia klientflanka vojo faras tiun decidon anstataŭ ĝi. Kie la postulo estas multaj ricevantoj, uzu subtenatan reproduktadon aŭ konscie elektitan alternativon, kaj skribu kiun vi elektis.

Fine, kontrolu ĉe la ricevanto sub mallarĝa observado: la ekzakta fonto, grupo kaj pordo, sur la interfaco kiun vi atendas, dum unu rajtigita ricevanto estas aliĝinta. SSM elektas sendanton, kaj elekto ne estas aŭtentikigo de tiu sendanto, nek permeso por alia multicast-trafiko trairi la saman politikon.