Pse multicast nuk kalon një VPN pa një plan

Dy vende mund të arrijnë në mënyrë të përsosur njëri-tjetrin përmes unicast-it dhe megjithatë të sillen sikur njëri prej tyre nuk e sheh njoftimin e zbulimit të printerit, rrjedhën IPTV ose rrahjen e zemrës së klasterit. Ky nuk është një tunel i prishur; ky është ndryshimi midis një destinacioni dhe një grupi. Dërgimi i multicast-it kërkon një model anëtarësie, gjendje përcjelljeje përgjatë rrugës dhe një ndërfaqe të gatshme për të mbajtur trafikun, dhe asnjë prej tyre nuk vjen nga një rrugë unicast. Kalimi nga grupi i aplikacionit te një marrës që funksionon është rruga më e shkurtër drejt një përgjigjeje.

Filloni me grupin dhe aplikacionin

Pyetni cilën adresë grupi përdor aplikacioni dhe për çfarë është trafiku. Një protokoll zbulimi që njofton shërbime, një rrjedhë transmetimi dhe paketat e përshëndetjes të një protokolli rrugëtimi janë tre probleme të ndryshme me tre përgjigje të ndryshme të pranueshme. Vetë adresa e grupit tregon shtrirjen: adresat në bllokun e kontrollit të rrjetit lokal nuk janë të destinuara të përcillen jashtë lidhjes nga rrugëtimi i zakonshëm, dhe aplikacionet që i përdorin ato zakonisht supozojnë një domen të vetëm transmetimi. Një rrjedhë transmetimi në një grup me shtrirje globale është një dizajn tjetër nga një protokoll zbulimi që pret që çdo pajisje të dëgjojë çdo pyetje, dhe vetëm i dyti interesohet për madhësinë e domenit të transmetimit.

Vendosni nëse kërkesa është shërbimi apo mekanizmi i zbulimit, sepse ato përgjigje ndryshojnë në kosto për një rend madhësie. Njëra kërkon një adresë që nuk ndryshon; tjetra kërkon një domen transmetimi të shtrirë përmes një lidhjeje të gjerë me gjithçka që rrjedh prej saj.

Zbulimi lokal duhet të ndalet

Multicast DNS i përshkruar në RFC 6762 është projektuar rreth një lidhjeje të vetme: pyetjet shkojnë te një grup fiks, përgjigjet dërgohen te i njëjti grup, dhe protokolli mbështetet në faktin që çdo pjesëmarrës i dëgjon të gjithë. Rrugëtuesit nuk e përcjellin atë trafik si parazgjedhje, dhe ky është një vendim dizajni, jo një lëshim. Kufiri ekziston që një pajisje në një ndërtesë të mos mund të njoftohet lirshëm në një tjetër. Një tunel që duket se rregullon zbulimin duke e mbajtur grupin kudo ka hequr atë kufi për çdo aplikacion, jo vetëm për atë që kishte nevojë për ndihmë.

Përsëritësit dhe reflektuesit ekzistojnë, dhe janë shërbime reale me pasoja reale: çdo emër i njoftuar në një vend bëhet i dukshëm në tjetrin, përfshirë emrat e pajisjeve që identifikojnë njerëz ose pajisje. Nëse kërkesa e vërtetë është që një shërbim i caktuar të jetë i gjetshëm, një regjistrim shërbimi i publikuar në DNS është zakonisht ndryshimi më i vogël, dhe zbulon një emër në vend të një rrjedhe emrash.

Tri gjëra që i duhen multicast-it të rrugëzuar

Multicast-i i rrugëzuar kërkon tri gjëra që punojnë së bashku: marrës që i bashkohen grupit, rrugëtues që mbajnë gjendje përcjelljeje për të, dhe një tunel që i trajton adresat e grupit si trafik për t'u mbajtur. Një tunel me një politikë që liston vetëm nënrrjeta unicast do ta hedhë poshtë trafikun e grupit në kufirin e kriptimit, dhe për këtë arsye simptomi i parë është shpesh heshtja dhe jo një gabim. Një ndërfaqe e bazuar në rrugë, si një tunel GRE ose VTI, mbart atë që i dërgon tabela e rrugëtimit, gjë që e bën grupin të arritshëm sapo ekziston gjendja e multicast-it.

Arritshmëria e burimit është gjysma e dytë. Protokollet e rrugëtimit multicast si PIM ndërtojnë pemë shpërndarjeje duke verifikuar që rruga përsëri te burimi është ajo e pritshme, kështu që një rrugë unicast që tregon diku tjetër e thyen pemën edhe kur anëtarësia në grup është e saktë. Instalimi i një rruge për marrësin nuk bën asgjë për atë verifikim, dhe ky është gabimi që prodhon një ping që funksionon dhe një rrjedhë që dështon. Verifikoni së pari rrugën e kthimit të burimit, pastaj shtoni anëtarësinë, dhe vetëm pastaj shikoni aplikacionin.

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

Dy rreshtat e parë tregojnë se ku është bashkuar hosti dhe çfarë përcjell kerneli, i treti tregon anëtarësinë e vetë aplikacionit, dhe i fundit rrugën unicast që do të përdorë verifikimi i rrugës së kundërt. Leximi i tyre së bashku dallon një aplikacion që nuk u bashkua kurrë nga një rrjet që nuk përcolli kurrë.

Provojeni me një burim dhe një marrës

Përpara se të prekni një konfigurim, konfirmoni që aplikacioni funksionon në një segment të vetëm. Nëse dështon lokalisht, rrugëtimi multicast nuk është problemi dhe asnjë ndryshim tuneli nuk do të ndihmojë. Më pas përsëritni me një marrës përmes tunelit dhe vëzhgoni paketat në të dyja anët e kufirit të kriptimit.

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

Paketat e dukshme brenda tunelit por që mungojnë jashtë tij tregojnë enkapsulim ose politikë; paketat e dukshme në të dyja anët pa përparim të aplikacionit tregojnë anëtarësinë e marrësit ose lidhjen e aplikacionit. Mbani regjistrimet të shkurtra dhe të filtruara, sepse një regjistrim i gjerë multicast në një segment të zënë është kryesisht zhurmë.

Zgjidhni një adresë shërbimi kur ju duhet vetëm shërbimi

Zbulimi ekziston për të gjetur diçka që lëviz. Një server me emër të qëndrueshëm nuk ka nevojë për zbulim, dhe një adresë e dokumentuar në DNS privat i përgjigjet pyetjes së vërtetë të përdoruesit pa shtrirë një domen transmetimi përmes një lidhjeje të gjerë. I njëjti arsyetim vlen për printerët, pajisjet dhe shërbimet web të brendshme. Një emër në DNS është i arritshëm nga çdo vend që i nevojitet, ndërsa nuk njofton asgjë për vendet që nuk i nevojitet, dhe vazhdon të punojë kur pajisja zëvendësohet me një tjetër me adresë të ndryshme.

Kur një protokoll kërkon vërtet multicast, kufizojeni atë në grup dhe në vendet që i nevojitet, dokumentoni pse dhe rishikoni vendimin kur aplikacioni ndryshon. Zgjerimi i zbulimit kudo është i lehtë një herë, dhe i vështirë për t'u tërhequr pas një viti pajisjesh që varen prej tij në heshtje.