SSM juu ya OpenVPN: kufuatilia chanzo kimoja na kikundi kimoja kutoka mwanzo hadi mwisho

Chagua mtiririko mmoja na mpokeaji mmoja, kisha fuatilia jozi hiyo kupitia kila hop badala ya kupima multicast kama kundi. Muundo mahususi kwa chanzo unashindikana hasa katika moja ya maeneo manne: mpokeaji hakujiunga kamwe, kipanga-njia kilikataa pakiti kwenye njia yake ya kurudi, kerneli haina hali, au handaki hakikuwasilisha nakala yoyote. Kufanya kazi kwa mpangilio huo hugharimu dakika kadhaa kwa kila hop na hukuambia ni ipi kati ya nne unayo kweli.

Kwanza bainisha chanzo, kikundi na mpokeaji

Andika thamani tatu kabla ya kugusa kifaa chochote: anwani ya chanzo kitakachotuma, anwani ya kikundi ambacho mpokeaji atajiunga nacho, na subnet ambayo mpokeaji anaishi. Kwa mtiririko wa IPv4 wa mfano, chanzo 10.50.0.10 na kikundi 232.20.30.40 ni aina ya jozi inayofaa muundo mahususi kwa chanzo. Kitu chochote kisicho wazi zaidi kuliko thamani hizo tatu hakiwezi kujaribiwa.

Masafa 232/8 yametengwa kwa multicast mahususi kwa chanzo, na modeli imeelezwa katika RFC 4607. Ikiwa kikundi chako kiko nje ya masafa hayo wakati unadhani unaendesha SSM, simama na uthibitishe kile utekelezaji unakusudia kwa kweli, kwa sababu uanachama wa mpokeaji na uamuzi wa upelekaji wa kipanga-njia vyote hutegemea modeli kuwa thabiti.

Hakikisha kwamba mpokeaji amejiunga na chanzo

Ripoti ya uanachama kwa kikundi pekee si ujio mahususi kwa chanzo. Muulize mpokeaji ni chanzo gani alichoomba, na kwenye kipanga-njia cha hop ya kwanza angalia hali ya kikundi kuona kama orodha ya vyanzo inaonekana. Ikiwa ripoti haibebi chanzo, kipanga-njia kitaitumia kama ujio kutoka chanzo chochote na muundo wote utashuka kimyakimya hadi kitu usichokipanga.

Kwenye mpokeaji wa Linux, hakikisha socket ilijisajili kwa nini hasa na kerneli ilirekodi nini. Faili ya usanidi ya programu si ushahidi; jedwali la uanachama ni ushahidi. Lisome wakati mpokeaji anaendesha kweli, kwa sababu ingizo linaweza kudumu kwa muda mfupi baada ya mchakato uliolizalisha kuondoka. Ingizo la zamani kutoka jaribio la awali ni chanzo cha kutegemewa cha kujiamini kwa uongo.

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

Ikiwa ujio upo pamoja na chanzo kinachotarajiwa, nenda kwenye vipanga-njia. Ikiwa haupo, usanidi wowote wa handaki hautasaidia, kwa sababu hakuna cha kupeleka.

Thibitisha njia ya kurudi kabla ya kuangalia handaki

Uelekezaji wa multicast hufanya ukaguzi wa njia ya kurudi, na pakiti inayowasili kwenye kiolesura kingine isipokuwa kile ambacho njia ya unicast inaelekeza hutunguliwa. Hii ndiyo sababu ya kawaida zaidi kwa nini mtiririko unaotumwa kwa wazi haufiki kamwe hop inayofuata, na hautoi hitilafu yoyote yenye manufaa katika ngazi ya programu.

Kwenye kipanga-njia kinachoelekea chanzo, linganisha njia kuelekea chanzo na kiolesura ambacho pakiti hufika kweli. Kwenye kipanga-njia kinachoelekea mpokeaji, fanya vivyo hivyo kwa subnet ya mpokeaji mwenyewe na uthibitishe kwamba orodha ya violesura vinavyotoka inajumuisha kiungo kuelekea hiyo. Kutokubaliana kwa mwelekeo wowote ni kushindikana kwa RPF, si kushindikana kwa uanachama.

Kisha uthibitishe kwamba TTL ya chanzo ni kubwa vya kutosha kuvuka hops zilizopangwa njia ulizozibuni. Mtiririko unaofanya kazi kwenye kipanga-njia cha kwanza na kufa kwenye cha pili mara nyingi ni swali la TTL na si swali la sera.

Soma hali ya multicast ya kerneli badala ya usanidi

Usanidi unakuambia ulichoomba; kerneli inakuambia kinachotokea. Kwenye kila hop ya Linux, soma maingizo ya uelekezaji wa multicast na uthibitishe kwamba orodha ya violesura vinavyoingia na vinavyotoka ipo kwa jozi kamili ya chanzo na kikundi. Ingizo la kikundi lenye chanzo cha jumla ni kitu kingine, na halitaeleza mtiririko mahususi kwa chanzo.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Daemon za uelekezaji huweka mtazamo wao wenyewe juu ya hali hiyo, na amri inayoichapisha inategemea ni utekelezaji upi umesakinishwa. Kanuni ni thabiti: muulize daemon maingizo yake ya juu kwa jozi, kisha muulize kerneli kama ingizo la upelekaji lipo. Daemon inayodhani inapeleka wakati kerneli haina ingizo ni tatizo la wigo wa usanidi kwenye mwenyeji huyo.

Wakati wawili hawakubaliani, rekebisha mwenyeji na si VPN. Hakuna chochote cha chini kinachoweza kufidia hop isiyopeleka mtiririko uliouuliza. Rekodi jozi, kiolesura kinachoingia na orodha inayotoka kwa kila hop wakati mtiririko unafanya kazi. Rekodi hiyo hubadilisha kushindikana kunakofuata kuwa ulinganisho badala ya uchunguzi mpya.

Amua jinsi handaki inavyojirudia kweli

Hapa ndipo multicast juu ya VPN huacha kuwa kawaida. Handaki la nukta-hadi-nukta huwasilisha pakiti kwa mwenza mmoja tu upande wa pili, kwa hivyo nakala hufika kwa mteja mmoja hasa. Sehemu iliyodaraja hujiendesha zaidi kama kiungo kilichoshirikiwa, kwa sababu handaki hubeba fremu na daraja huamua nini cha kufurika. Hizi ni modeli tofauti za uwasilishaji, na muundo unaodhani ya pili wakati unaendesha ya kwanza utaonekana kufanya kazi kwa mpokeaji mmoja na kushindikana kwa anayefuata.

Kwa zaidi ya mpokeaji mmoja kupitia seva ya nukta nyingi, uzalishaji nakala lazima ubunwe kwa uwazi. Kusakinisha njia ya multicast kwenye lango hakufundishi seva ya VPN ni wenzi gani wanapaswa kupokea nakala, na hakuna njia ya upande wa mteja inayofanya uamuzi huo kwa niaba yake. Ambapo hitaji ni wapokeaji wengi, tumia uzalishaji nakala unaoungwa mkono au mbadala uliochaguliwa kwa makusudi, na uandike ni upi uliochagua.

Mwishowe, thibitisha kwa mpokeaji chini ya uchunguzi mwembamba: chanzo, kikundi na bandari kamili, kwenye kiolesura unachotarajia, wakati mpokeaji mmoja aliyeidhinishwa amejiunga. SSM huchagua mtumaji, na uteuzi si uthibitisho wa mtumaji huyo, wala si ruhusa kwa trafiki nyingine ya multicast kuvuka sera hiyo hiyo.