Ինչու է մուլթիքաստը առանց պլանի VPN-ով չի անցնում

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

Սկսեք խմբից և հավելվածից

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

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

Տեղական հայտնաբերումը պետք է դադարի

RFC 6762-ում նկարագրված Multicast DNS-ը ձևավորված է մեկ կապուղու շուրջ. հարցումները գնում են ֆիքսված խմբի, պատասխանները ուղարկվում են նույն խմբին, և արձանագրությունը հույսը դնում է այն բանի վրա, որ յուրաքանչյուր մասնակից լսում է բոլորին։ Երթուղիչները լռելյայն չեն փոխանցում այդ երթևեկությունը, և դա ձևավորման որոշում է, ոչ թե բացթողում։ Սահմանը գոյություն ունի, որպեսզի մի շենքի սարքը չկարողանա հանգիստ հայտարարել իրեն մյուսում։ Թունելը, որը կարծես թե ուղղում է հայտնաբերումը՝ խումբը ամենուր տանելով, հեռացրել է այդ սահմանը յուրաքանչյուր հավելվածի համար, ոչ միայն նրա, որին օգնություն էր պետք։

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

Երեք բան, որ ուղղորդված մուլթիքաստին անհրաժեշտ է

Ուղղորդված մուլթիքաստին անհրաժեշտ է երեք բան միասին աշխատելիս. խմբին միացող ընդունիչներ, նրա համար փոխանցման վիճակ պահող երթուղիչներ և թունել, որը խմբի հասցեները վերաբերվում է որպես կրելի երթևեկություն։ Թունելը, որի քաղաքականությունը թվարկում է միայն յունիքաստ ենթացանցեր, խմբի երթևեկությունը կգցի գաղտնագրման սահմանին, և դրա համար է, որ առաջին ախտանիշը հաճախ լռությունն է, ոչ թե սխալը։ Երթուղու վրա հիմնված ինտերֆեյսը, ինչպիսին GRE կամ VTI թունելն է, կրում է այն, ինչ երթուղային աղյուսակը ուղարկում է նրա մեջ, ինչը խումբը հասանելի է դարձնում, հենց որ մուլթիքաստի վիճակը գոյություն ունի։

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

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

Առաջին երկու տողերը ցույց են տալիս, թե ինչին է միացել հոսթը և ինչ է փոխանցում միջուկը, երրորդը ցույց է տալիս հավելվածի սեփական անդամակցությունը, իսկ վերջինը՝ այն յունիքաստ ուղին, որը կօգտագործի հակադարձ ուղու ստուգումը։ Դրանք միասին կարդալը տարբերում է երբեք չմիացած հավելվածը երբեք չփոխանցած ցանցից։

Ապացուցեք մեկ աղբյուրով և մեկ ընդունիչով

Կարգավորումը ձեռք տալուց առաջ հաստատեք, որ հավելվածը աշխատում է մեկ սեգմենտում։ Եթե այն տեղական մակարդակով ձախողվում է, մուլթիքաստի երթուղավորումը խնդիրը չէ և ոչ մի թունելի փոփոխություն չի օգնի։ Այնուհետև կրկնեք մեկ ընդունիչով թունելի միջով և դիտեք փաթեթները գաղտնագրման սահմանի երկու կողմերում։

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

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

Ընտրեք ծառայության հասցե, երբ միայն ծառայությունն է պետք

Հայտնաբերումը գոյություն ունի շարժվող ինչ-որ բան գտնելու համար։ Կայուն անունով սերվերը հայտնաբերման կարիք չունի, և մասնավոր DNS-ում փաստաթղթավորված հասցեն պատասխանում է օգտվողի իրական հարցին՝ առանց հեռարձակման տիրույթը լայն տարածքի կապուղու վրա ընդլայնելու։ Նույն տրամաբանությունը վերաբերում է տպիչներին, սարքերին և ներքին վեբ ծառայություններին։ DNS-ի անունը հասանելի է յուրաքանչյուր տեղամասից, որին այն պետք է, միաժամանակ ոչինչ չհայտարարելով այն տեղամասերին, որոնց պետք չէ, և այն շարունակում է աշխատել, երբ սարքը փոխարինվում է այլ հասցեով մեկով։

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