SSM sa OpenVPN: pagsubaybay sa Isang Pinagmulan at Grupo mula Simula hanggang Katapusan

Pumili ng isang stream at isang tatanggap, pagkatapos ay sundan ang pares na iyon sa bawat hop sa halip na subukan ang multicast bilang kategorya. Nabibigo ang disenyong partikular sa pinagmulan sa eksaktong isa sa apat na lugar: hindi kailanman sumali ang tatanggap, tinanggihan ng router ang packet sa pabalik na ruta nito, walang estado ang kernel, o hindi kailanman naghatid ng kopya ang tunnel. Ang pagtatrabaho sa ganoong pagkakasunod-sunod ay tumatagal ng ilang minuto bawat hop at sinasabi sa iyo kung alin sa apat ang talagang mayroon ka.

I-set muna ang pinagmulan, grupo at tatanggap

Isulat ang tatlong halaga bago hawakan ang anumang aparato: ang address ng pinagmulang magpapadala, ang address ng grupong sasalihan ng tatanggap, at ang subnet kung saan naninirahan ang tatanggap. Para sa isang halimbawang IPv4 stream, ang pinagmulang 10.50.0.10 at grupong 232.20.30.40 ay ang uri ng pares na umaangkop sa disenyong partikular sa pinagmulan. Anumang mas malabo kaysa sa tatlong halagang iyon ay hindi masusubok.

Ang saklaw na 232/8 ay nakalaan para sa multicast na partikular sa pinagmulan, at ang modelo ay inilarawan sa RFC 4607. Kung ang iyong grupo ay nasa labas ng saklaw na iyon habang inaakala mong nagpapatakbo ka ng SSM, huminto at kumpirmahin kung ano talaga ang layunin ng deployment, dahil ang pagsali ng tatanggap at ang desisyon ng pagpapasa ng router ay parehong nakadepende sa pagkakapare-pareho ng modelo.

Suriin kung sumali ang tatanggap sa pinagmulan

Ang ulat ng pagiging miyembro para sa grupo lamang ay hindi pagsali na partikular sa pinagmulan. Tanungin ang tatanggap kung aling pinagmulan ang hiniling nito, at sa router ng unang hop tingnan ang estado ng grupo upang makita kung may lumilitaw na listahan ng pinagmulan. Kung walang pinagmulang dala ang ulat, ituturing ito ng router bilang pagsali mula sa anumang pinagmulan at tahimik na bababa ang buong disenyo sa isang bagay na hindi mo pinlano.

Sa isang Linux na tatanggap, suriin kung ano talaga ang sinubskrayb ng socket at kung ano ang naitala ng kernel. Ang configuration file ng application ay hindi ebidensya; ang membership table ang ebidensya. Basahin ito habang talagang tumatakbo ang tatanggap, dahil ang isang entry ay maaaring manatili nang maikling panahon matapos lumabas ang prosesong gumawa nito. Ang lumang entry mula sa naunang pagsubok ay isang mapagkakatiwalaang pinagmulan ng huwad na kumpiyansa.

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

Kung naroroon ang pagsali kasama ang inaasahang pinagmulan, pumunta sa mga router. Kung wala ito, walang tulong ang anumang configuration ng tunnel, dahil walang maipapasa.

I-verify ang pabalik na ruta bago mo tingnan ang tunnel

Ang multicast routing ay nagsasagawa ng pabalik na ruta check, at ang packet na dumarating sa ibang interface kaysa sa itinuturo ng unicast route ay itinatapon. Ito ang pinakakaraniwang dahilan kung bakit ang isang stream na malinaw na ipinapadala ay hindi kailanman umabot sa susunod na hop, at wala itong nagagawa na kapaki-pakinabang na error sa antas ng application.

Sa router na nakaharap sa pinagmulan, ihambing ang ruta patungo sa pinagmulan sa interface kung saan talagang dumarating ang mga packet. Sa router na nakaharap sa tatanggap, gawin ang parehong bagay para sa sariling subnet ng tatanggap at kumpirmahin na kasama sa listahan ng papalabas na interface ang link patungo rito. Ang hindi pagkakatugma sa alinmang direksyon ay kabiguan ng RPF, hindi kabiguan ng pagiging miyembro.

Pagkatapos, kumpirmahin na ang TTL ng pinagmulan ay sapat na malaki upang makaligtas sa mga rutadong hop na dinisenyo mo. Ang stream na gumagana sa unang router at namamatay sa pangalawa ay madalas na usapin ng TTL at hindi usapin ng patakaran.

Basahin ang multicast state ng kernel sa halip na ang configuration

Sinasabi ng configuration kung ano ang hiningi mo; sinasabi ng kernel kung ano ang nangyayari. Sa bawat Linux hop, basahin ang mga entry ng multicast routing at kumpirmahin na may listahan ng papasok at papalabas na interface para sa eksaktong pares ng pinagmulan at grupo. Ang entry para sa grupo na may wildcard na pinagmulan ay ibang bagay, at hindi nito ipapaliwanag ang stream na partikular sa pinagmulan.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Ang mga routing daemon ay may sariling pananaw sa ibabaw ng estadong iyon, at ang command na naglilimbag nito ay nakadepende sa kung aling implementasyon ang naka-install. Ang prinsipyo ay pare-pareho: tanungin ang daemon para sa upstream entry nito para sa pares, pagkatapos ay tanungin ang kernel kung may forwarding entry. Ang daemon na inaakalang nagpapasa habang walang entry ang kernel ay problema ng saklaw ng configuration sa host na iyon.

Kapag hindi nagkakasundo ang dalawa, ayusin ang host at hindi ang VPN. Wala sa ibaba ang makakabawi sa isang hop na hindi nagpapasa ng stream na itinanong mo. Itala ang pares, ang papasok na interface at ang papalabas na listahan para sa bawat hop habang gumagana ang stream. Ang talaang iyon ay ginagawang paghahambing ang susunod na kabiguan sa halip na bagong imbestigasyon.

Magpasya kung paano talaga nagre-replicate ang tunnel

Dito tumitigil ang multicast sa ibabaw ng VPN na maging karaniwang gawain. Ang point-to-point tunnel ay naghahatid ng packet sa nag-iisang peer sa kabilang dulo, kaya ang isang kopya ay umaabot sa eksaktong isang kliyente. Ang naka-bridge na segment ay kumikilos nang mas katulad ng shared link, dahil dinadala ng tunnel ang frame at ang bridge ang nagpapasya kung ano ang babahain. Ito ay magkaibang modelo ng paghahatid, at ang disenyong ipinapalagay ang pangalawa habang pinapatakbo ang una ay mukhang gagana para sa isang tatanggap at mabibigo para sa susunod.

Para sa higit sa isang tatanggap sa pamamagitan ng multipoint server, ang replication ay dapat na tahasang dinisenyo. Ang pag-install ng multicast route sa gateway ay hindi nagtuturo sa VPN server kung aling mga peer ang dapat makatanggap ng kopya, at walang ruta sa panig ng kliyente ang gumagawa ng desisyong iyon para dito. Kung saan ang pangangailangan ay maraming tatanggap, gumamit ng suportadong replication o sinadyang piniling alternatibo, at isulat kung alin ang pinili mo.

Sa huli, i-verify sa tatanggap sa ilalim ng makitid na obserbasyon: ang eksaktong pinagmulan, grupo at port, sa interface na inaasahan mo, habang sumali ang isang awtorisadong tatanggap. Pumipili ang SSM ng sender, at ang pagpili ay hindi pagpapatunay ng sender na iyon, at hindi rin permiso para sa ibang multicast traffic na tumawid sa parehong patakaran.