Wêrom multicast gjin VPN oerstekt sûnder plan

Twa lokaasjes kinne inoar perfekt berikke fia unicast en har dochs gedrage as koe ien fan har de ûntdekkingskundiging fan de printer, de IPTV-stream of de hertslach fan it cluster net sjen. Dat is gjin brutsen tunnel; it is it ferskil tusken in bestimming en in groep. Multicast-ôflevering hat in lidmaatskipmodel, trochstjoerstatus lâns de wei en in ynterface nedich dy't ree is it ferkear te dragen, en gjin fan dy komt fan in unicast-route. Fan 'e groep fan 'e applikaasje nei ien wurkjende ûntfanger rinne is de koartste wei nei in antwurd.

Begjin mei de groep en de applikaasje

Freegje hokker groepadres de applikaasje brûkt en wêr't it ferkear foar is. In ûntdekkingsprotokol dat tsjinsten oankundiget, in streamingfeed en de hallo-pakketten fan in routingprotokol binne trije ferskillende problemen mei trije ferskillende akseptabele antwurden. It groepadres sels fertelt it omfang: adressen yn it lokale netwurkbehearblok binne net bedoeld om troch gewoane routing fan 'e link ôf trochstjoerd te wurden, en applikaasjes dy't se brûke, nimme meastentiids ien broadcast-domein oan. In streamingfeed op in groep mei wrâldwiid omfang is in oar ûntwerp as in ûntdekkingsprotokol dat ferwachtet dat elk apparaat elke fraach heart, en allinnich it twadde jout om 'e grutte fan it broadcast-domein.

Beslút oft de eask de tsjinst of it ûntdekkingsmeganisme is, want dy antwurden ferskille yn kosten mei in oarder fan grutte. It iene freget om in adres dat net feroaret; it oare freget om in broadcast-domein dat oer in WAN-ferbining útwreide is mei alles wat dêrút folget.

Lokale ûntdekking heart te stopjen

Multicast DNS sa't it yn RFC 6762 beskreaun is, is ûntwurpen om ien link: fragen geane nei in fêste groep, antwurden wurde nei deselde groep stjoerd, en it protokol fertrout derop dat elke dielnimmer elkenien heart. Routers stjoere dat ferkear net standert troch, en dat is in ûntwerpbeslissing en gjin fersom. De grins bestiet sadat in apparaat yn ien gebou him net samar yn in oar oankundigje kin. In tunnel dy't ûntdekking liket te reparearjen troch de groep oeral te dragen, hat dy grins foar elke applikaasje weilitten, net allinnich foar de iene dy't help nedich hie.

Werhellers en refleksjes bestean, en it binne echte tsjinsten mei echte gefolgen: elke namme dy't op ien lokaasje oankundige wurdt, wurdt op it oare sichtber, ynklusyf apparaatnammen dy't minsken of apparatuer identifisearje. As de echte eask is dat in spesifike tsjinst fynber is, dan is in tsjinstrekord publisearre yn DNS meastentiids de lytsere feroaring, en it iepenbiere ien namme yn plak fan in stream fan nammen.

Trije dingen dy't routed multicast nedich hat

Routed multicast hat trije dingen nedich dy't gearwurkje: ûntfangers dy't by de groep geane, routers dy't trochstjoerstatus foar har byhâlde, en in tunnel dy't de groepadressen as te dragen ferkear behannelet. In tunnel mei in belied dat allinnich unicast-subnetten neamt, sil it ferkear fan 'e groep by de fersiferinggrins falle litte, en dêrom is it earste symptoom faak stilte yn plak fan in flater. In op rûtes basearre ynterface, lykas in GRE- of VTI-tunnel, draacht wat de routingtabel deryn stjoert, wat de groep berikber makket sadree't de multicast-status bestiet.

Berikberens fan 'e boarne is de twadde helte. Multicast-routingprotokollen lykas PIM bouwe distribúsjebeammen troch te kontrolearjen dat de wei werom nei de boarne de ferwachte is, dus in unicast-route dy't earne oars hinne wiist, brekt de beam sels as it groepslidmaatskip goed is. In rûte foar de ûntfanger ynstallearje docht neat foar dy kontrôle, en dat is de flater dy't in wurkjende ping en in mislearjende stream jout. Kontrolearje earst de weromwei fan 'e boarne, foegje dan lidmaatskip ta, en sjoch pas dêrnei nei de applikaasje.

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

De earste twa rigels litte sjen wêr't de host by is en wat de kernel trochstjoert, de tredde lit it eigen lidmaatskip fan 'e applikaasje sjen, en de lêste de unicast-wei dy't de omkearde-wei-kontrôle brûke sil. Se tegearre lêze ûnderskiedt in applikaasje dy't nea bygie fan in netwurk dat nea trochstjoerde.

Bewiis it mei ien boarne en ien ûntfanger

Foardat jo in konfiguraasje oanreitsje, befêstigje dat de applikaasje op ien segment wurket. As it lokaal mislearret, is multicast-routing net it probleem en sil gjin tunnelferoaring helpe. Werhelje dan mei ien ûntfanger oer de tunnel en sjoch nei de pakketten oan beide kanten fan 'e fersiferinggrins.

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

Pakketten dy't binnen de tunnel sichtber binne mar derbûten ôfwêzich, wize op inkapseling of belied; pakketten dy't oan beide kanten sichtber binne sûnder foarútgong yn 'e applikaasje wize op it lidmaatskip fan 'e ûntfanger of de binding fan 'e applikaasje. Hâld opnames koart en filtere, want in brede multicast-opname op in drok segment is benammen lûd.

Kies in tsjinstadres as jo allinnich de tsjinst nedich hawwe

Ûntdekking bestiet om iets te finen dat beweecht. In tsjinner mei in stabile namme hat gjin ûntdekking nedich, en in dokumintearre adres yn privee DNS beantwurdet de echte fraach fan 'e brûker sûnder in broadcast-domein oer in WAN-ferbining út te wreidzjen. Deselde redenearring jildt foar printers, apparaten en ynterne websjinsten. In namme yn DNS is berikber fan elk lokaasje dat it nedich hat wylst it neat oankundiget oan 'e lokaasjes dy't it net nedich hawwe, en it bliuwt wurkjen as it apparaat ferfongen wurdt troch ien mei in oar adres.

As in protokol wier multicast easket, beheinje it dan ta de groep en de lokaasjes dy't it nedich hawwe, dokumintearje wêrom, en besjoch it beslút op 'e nij as de applikaasje feroaret. Ûntdekking oeral útwreidzje is maklik om ien kear te dwaan, en dreech werom te draaien nei in jier fan apparaten dy't der stil fan ôfhingje.