SSM mbi OpenVPN: ndjekja e një burimi dhe një grupi nga fillimi në fund

Zgjidhni një rrjedhë dhe një marrës, më pas ndiqni atë çift nëpër çdo hop në vend që ta provoni multicast si kategori. Një dizajn specifik për burimin dështon saktësisht në një nga katër vende: marrësi nuk u bashkua kurrë, routeri e refuzoi paketën në rrugën e kthimit, kernel-i nuk ka gjendje, ose tuneli nuk dorëzoi kurrë një kopje. Puna në atë rend kushton minuta për hop dhe ju tregon se cilin nga të katërt e keni në të vërtetë.

Fillimisht fiksoni burimin, grupin dhe marrësin

Shkruani tre vlera përpara se të prekni çdo pajisje: adresën e burimit që do të dërgojë, adresën e grupit ku do të bashkohet marrësi dhe nënrrjetin ku jeton marrësi. Për një rrjedhë ilustrative IPv4, një burim 10.50.0.10 dhe një grup 232.20.30.40 janë pikërisht ai lloj çifti që përshtatet me një dizajn specifik për burimin. Çdo gjë më e paqartë se këto tre vlera nuk mund të provohet.

Gama 232/8 është e rezervuar për multicast specifik për burimin, dhe modeli përshkruhet në RFC 4607. Nëse grupi juaj është jashtë asaj game ndërsa mendoni se po ekzekutoni SSM, ndaloni dhe konfirmoni çfarë synon në të vërtetë vendosja, sepse bashkimi i marrësit dhe vendimi i përcjelljes së routerit varen të dy nga fakti që modeli të jetë konsistent.

Kontrolloni që marrësi është bashkuar me burimin

Një raport anëtarësimi vetëm për grupin nuk është bashkim specifik për burimin. Pyetni marrësin se çfarë burimi kërkoi, dhe në routerin e hopit të parë shikoni gjendjen e grupit për të parë nëse shfaqet një listë burimesh. Nëse raporti nuk mbart asnjë burim, routeri do ta trajtojë atë si bashkim nga çdo burim dhe i gjithë dizajni degradon në heshtje në diçka që nuk e kishit planifikuar.

Në një marrës Linux, kontrolloni se çfarë ka abonuar në të vërtetë socket-i dhe çfarë ka regjistruar kernel-i. Skedari i konfigurimit të aplikacionit nuk është provë; tabela e anëtarësimit është provë. Lexojeni atë ndërsa marrësi është vërtet në punë, sepse një hyrje mund të mbetet për pak kohë pasi procesi që e krijoi ka dalë. Një hyrje e vjetër nga një test i mëparshëm është burim i besueshëm i vetëbesimit të rremë.

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

Nëse bashkimi është i pranishëm me burimin e pritur, kaloni te routerat. Nëse mungon, asnjë konfigurim tuneli nuk do të ndihmojë, sepse nuk ka asgjë për të përcjellë.

Verifikoni rrugën e kthimit përpara se të shikoni tunelin

Rrugëtimi multicast kryen një kontroll të rrugës së kthimit, dhe një paketë që arrin në një ndërfaqe të ndryshme nga ajo ku tregon rruga unicast hidhet. Kjo është arsyeja më e zakonshme pse një rrjedhë që po dërgohet qartë nuk arrin kurrë hopin tjetër, dhe nuk prodhon asnjë gabim të dobishëm në nivel aplikacioni.

Në routerin e kthyer nga burimi, krahasoni rrugën drejt burimit me ndërfaqen ku paketat vërtet mbërrijnë. Në routerin e kthyer nga marrësi, bëni të njëjtën gjë për nënrrjetin e vetë marrësit dhe konfirmoni që lista e ndërfaqeve dalëse përfshin lidhjen drejt tij. Një mospërputhje në çdo drejtim është dështim i RPF, jo dështim anëtarësimi.

Më pas konfirmoni që TTL i burimit është mjaft i madh për të mbijetuar hopet e rrugëtuara që keni projektuar. Një rrjedhë që funksionon në routerin e parë dhe vdes në të dytin është shpesh çështje TTL dhe jo çështje politike.

Lexoni gjendjen multicast të kernel-it në vend të konfigurimit

Konfigurimi ju tregon çfarë kërkuat; kernel-i ju tregon çfarë po ndodh. Në çdo hop Linux, lexoni hyrjet e rrugëtimit multicast dhe konfirmoni që për çiftin e saktë të burimit dhe grupit ekziston një listë e ndërfaqeve hyrëse dhe dalëse. Një hyrje për grupin me një burim të përgjithshëm është objekt tjetër dhe nuk do të shpjegojë një rrjedhë specifike për burimin.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Demonët e rrugëtimit mbajnë pamjen e tyre mbi atë gjendje, dhe komanda që e shtyp atë varet nga implementimi i instaluar. Parimi është konstant: pyetni demonin për hyrjen e tij të sipërme për çiftin, pastaj pyetni kernel-in nëse ekziston një hyrje përcjelljeje. Një demon që mendon se po përcjell ndërsa kernel-i nuk ka hyrje është problem i shtrirjes së konfigurimit në atë host.

Kur të dy nuk merren vesh, rregulloni hostin dhe jo VPN-në. Asgjë në rrjedhën e poshtme nuk mund të kompensojë një hop që nuk përcjell rrjedhën për të cilën pyetët. Regjistroni çiftin, ndërfaqen hyrëse dhe listën dalëse për çdo hop ndërsa rrjedha funksionon. Ai regjistrim e kthen dështimin tjetër në krahasim në vend të një hetimi të ri.

Vendosni se si tuneli vërtet replikon

Këtu multicast mbi një VPN pushon së qeni rutinë. Një tunel pikë-pikë dorëzon një paketë te i vetmi bashkëmendimtar në anën tjetër, kështu që një kopje arrin saktësisht te një klient. Një segment i urëzuar sillet më shumë si një lidhje e përbashkët, sepse tuneli mbart kornizën dhe ura vendos çfarë të përmbytë. Këto janë modele të ndryshme dorëzimi, dhe një dizajn që supozon të dytin ndërsa ekzekuton të parin do të duket se funksionon për një marrës dhe do të dështojë për të tjetrin.

Për më shumë se një marrës përmes një serveri shumëpikësh, replikimi duhet të projektohet në mënyrë eksplicite. Instalimi i një rruge multicast në portë nuk e mëson serverin VPN se cilët bashkëmendimtarë duhet të marrin një kopje, dhe asnjë rrugë në anën e klientit nuk e merr atë vendim në vend të tij. Aty ku kërkesa është shumë marrës, përdorni replikim të mbështetur ose një alternativë të zgjedhur me qëllim, dhe shkruani cilën zgjodhët.

Së fundi, verifikoni te marrësi nën një vëzhgim të ngushtë: burimin, grupin dhe portin e saktë, në ndërfaqen që prisni, ndërsa një marrës i autorizuar është i bashkuar. SSM zgjedh një dërgues, dhe zgjedhja nuk është vërtetim i atij dërguesi, as leje për trafik tjetër multicast për të kaluar të njëjtën politikë.