SSM OpenVPN-ի վրայով. մեկ աղբյուր և խումբ սկզբից մինչև վերջ

Ընտրեք մեկ հոսք և մեկ ստացող, ապա հետևեք այդ զույգին յուրաքանչյուր ցատկով՝ multicast-ը որպես կատեգորիա փորձարկելու փոխարեն։ Աղբյուրին բնորոշ նախագիծը ձախողվում է ուղիղ չորս տեղերից մեկում՝ ստացողը երբեք չի միացել, երթուղիչը մերժել է փաթեթը վերադարձի ուղու վրա, միջուկը վիճակ չունի, կամ թունելը երբեք պատճեն չի հասցրել։ Այդ հերթականությամբ աշխատելը արժենում է րոպեներ յուրաքանչյուր ցատկի համար և ասում է, թե չորսից որն ունեք իրականում։

Նախ ամրացրեք աղբյուրը, խումբը և ստացողը

Գրեք երեք արժեք նախքան որևէ սարքի դիպչելը՝ ուղարկող աղբյուրի հասցեն, այն խմբի հասցեն, որին կմիանա ստացողը, և այն ենթացանցը, որտեղ գտնվում է ստացողը։ Օրինակելի IPv4 հոսքի համար 10.50.0.10 աղբյուրը և 232.20.30.40 խումբը հենց այն զույգն են, որը համապատասխանում է աղբյուրին բնորոշ նախագծին։ Այդ երեք արժեքներից ավելի անորոշ որևէ բան հնարավոր չէ փորձարկել։

232/8 միջակայքը վերապահված է աղբյուրին բնորոշ multicast-ի համար, և մոդելը նկարագրված է RFC 4607-ում։ Եթե ձեր խումբը գտնվում է այդ միջակայքից դուրս, մինչդեռ կարծում եք, թե SSM եք աշխատեցնում, կանգ առեք և հաստատեք, թե տեղակայումն իրականում ինչ է նկատի ունեցել, որովհետև ստացողի միացումը և երթուղիչի փոխանցման որոշումը երկուսն էլ կախված են մոդելի հետևողականությունից։

Ստուգեք, որ ստացողը միացել է աղբյուրին

Միայն խմբի համար անդամակցության հաշվետվությունը աղբյուրին բնորոշ միացում չէ։ Հարցրեք ստացողին, թե որ աղբյուրն է նա պահանջել, և առաջին ցատկի երթուղիչում նայեք խմբի վիճակին՝ տեսնելու, թե արդյոք աղբյուրների ցանկ է հայտնվում։ Եթե հաշվետվությունը աղբյուր չի կրում, երթուղիչը այն կդիտարկի որպես ցանկացած աղբյուրի միացում, և ամբողջ նախագիծը լուռ կվերածվի մի բանի, ինչը դուք չեք պլանավորել։

Linux ստացողի վրա ստուգեք, թե ինչին է իրականում բաժանորդագրվել սոքեթը և ինչ է գրանցել միջուկը։ Հավելվածի կարգավորման ֆայլը ապացույց չէ. ապացույցը անդամակցության աղյուսակն է։ Կարդացեք այն, երբ ստացողն իրականում աշխատում է, որովհետև գրառումը կարող է կարճ ժամանակ մնալ այն պրոցեսի ավարտից հետո, որը ստեղծել է այն։ Հին թեստից մնացած գրառումը կեղծ վստահության հուսալի աղբյուր է։

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

Եթե միացումը առկա է սպասվող աղբյուրով, անցեք երթուղիչներին։ Եթե այն բացակայում է, ոչ մի թունելի կարգավորում չի օգնի, որովհետև փոխանցելու բան չկա։

Ստուգեք վերադարձի ուղին նախքան թունելին նայելը

Multicast երթուղավորումը կատարում է վերադարձի ուղու ստուգում, և այն փաթեթը, որը հասնում է մի ինտերֆեյսով, որը տարբերվում է նրանից, ուր ցույց է տալիս unicast երթուղին, հեռացվում է։ Սա ամենատարածված պատճառն է, որ ակնհայտորեն ուղարկվող հոսքը երբեք չի հասնում հաջորդ ցատկին, և այն բոլորովին օգտակար սխալ չի առաջացնում հավելվածի մակարդակում։

Աղբյուրին ուղղված երթուղիչում համեմատեք դեպի աղբյուր տանող երթուղին այն ինտերֆեյսի հետ, որով փաթեթները իրականում ժամանում են։ Ստացողին ուղղված երթուղիչում նույնը արեք ստացողի սեփական ենթացանցի համար և հաստատեք, որ ելքային ինտերֆեյսների ցանկը ներառում է դեպի այն տանող կապը։ Ցանկացած ուղղությամբ անհամապատասխանությունը RPF ձախողում է, ոչ թե անդամակցության ձախողում։

Ապա հաստատեք, որ աղբյուրի TTL-ը բավականաչափ մեծ է ձեր նախագծած երթուղավորված ցատկերին դիմանալու համար։ Հոսքը, որն աշխատում է առաջին երթուղիչում և մեռնում երկրորդում, հաճախ TTL-ի հարց է, ոչ թե քաղաքականության։

Կարդացեք միջուկի multicast վիճակը, ոչ թե կարգավորումը

Կարգավորումը ձեզ ասում է, թե ինչ եք խնդրել, միջուկը՝ ինչ է կատարվում։ Յուրաքանչյուր Linux ցատկում կարդացեք multicast երթուղավորման գրառումները և հաստատեք, որ աղբյուր-խումբ ճշգրիտ զույգի համար գոյություն ունի մուտքային և ելքային ինտերֆեյսների ցանկ։ Խմբի համար ընդհանրական աղբյուրով գրառումը այլ օբյեկտ է և չի բացատրի աղբյուրին բնորոշ հոսքը։

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Երթուղավորման դեմոնները պահում են իրենց տեսքը այդ վիճակի վրա, և այն տպող հրամանը կախված է նրանից, թե որ իրականացումն է տեղադրված։ Սկզբունքը հաստատուն է. հարցրեք դեմոնին զույգի վերին գրառումը, ապա հարցրեք միջուկին՝ արդյոք փոխանցման գրառում գոյություն ունի։ Դեմոնը, որը կարծում է, թե փոխանցում է, մինչդեռ միջուկը գրառում չունի, այդ հոսթի կարգավորման շրջանակի խնդիր է։

Երբ երկուսը չեն համաձայնում, ուղղեք հոսթը, ոչ թե VPN-ը։ Ստորև ոչինչ չի կարող փոխհատուցել այն ցատկը, որը չի փոխանցում ձեր հարցրած հոսքը։ Գրանցեք զույգը, մուտքային ինտերֆեյսը և ելքային ցանկը յուրաքանչյուր ցատկի համար, մինչ հոսքը աշխատում է։ Այդ գրանցումը հաջորդ ձախողումը դարձնում է համեմատություն նոր հետաքննության փոխարեն։

Որոշեք, թե ինչպես է թունելն իրականում կրկնօրինակում

Այստեղ է, որ VPN-ի վրայով multicast-ը դադարում է սովորական լինելուց։ Կետ-կետ թունելը փաթեթը հասցնում է մյուս ծայրում գտնվող միակ գործընկերոջը, այնպես որ պատճենը հասնում է ուղիղ մեկ հաճախորդի։ Կամրջված սեգմենտն իրեն պահում է ավելի շատ որպես ընդհանուր կապ, որովհետև թունելը տանում է կադրը, և կամուրջը որոշում է, թե ինչ ողողել։ Սրանք առաքման տարբեր մոդելներ են, և այն նախագիծը, որը ենթադրում է երկրորդը՝ աշխատեցնելով առաջինը, կթվա աշխատող մեկ ստացողի համար և կձախողվի հաջորդի համար։

Մեկից ավելի ստացողի համար բազմակետ սերվերի միջով կրկնօրինակումը պետք է նախագծվի բացահայտ։ Դարպասի վրա multicast երթուղի տեղադրելը չի սովորեցնում VPN սերվերին, թե որ գործընկերները պետք է պատճեն ստանան, և ոչ մի կլիենտային երթուղի չի կայացնում այդ որոշումը նրա փոխարեն։ Այնտեղ, որտեղ պահանջը շատ ստացողներ են, օգտագործեք աջակցվող կրկնօրինակում կամ գիտակցաբար ընտրված այլընտրանք, և գրեք, թե որն եք ընտրել։

Վերջում ստուգեք ստացողի մոտ նեղ դիտարկմամբ՝ ճշգրիտ աղբյուրը, խումբը և պորտը, ձեր սպասած ինտերֆեյսում, մինչ մեկ լիազորված ստացող միացած է։ SSM-ը ընտրում է ուղարկող, և ընտրությունը այդ ուղարկողի նույնականացում չէ, ինչպես նաև թույլտվություն չէ, որ այլ multicast երթևեկություն անցնի նույն քաղաքականությունը։