Zakaj multicast ne prečka VPN brez načrta

Dve lokaciji se lahko prek unicasta popolnoma dosežeta in se vseeno obnašata, kot da ena od njiju ne vidi najave odkrivanja tiskalnika, toka IPTV ali srčnega utripa gruče. To ni pokvarjen tunel; to je razlika med ciljem in skupino. Dostava multicasta potrebuje model članstva, stanje posredovanja vzdolž poti in vmesnik, pripravljen nositi promet, in nič od tega ne prihaja iz unicast poti. Hoja od skupine aplikacije do enega delujočega prejemnika je najkrajša pot do odgovora.

Začnite s skupino in aplikacijo

Vprašajte, kateri naslov skupine uporablja aplikacija in čemu je promet namenjen. Protokol odkrivanja, ki oglašuje storitve, pretočni tok in paketi pozdrava usmerjevalnega protokola so trije različni problemi s tremi različnimi sprejemljivimi odgovori. Naslov skupine sam pove obseg: naslovi v bloku nadzora lokalnega omrežja niso namenjeni posredovanju izven povezave z običajnim usmerjanjem, in aplikacije, ki jih uporabljajo, običajno predpostavljajo eno samo domeno oddajanja. Pretočni tok na skupini z globalnim obsegom je drugačna zasnova kot protokol odkrivanja, ki pričakuje, da bo vsaka naprava slišala vsako poizvedbo, in le drugega zanima velikost domene oddajanja.

Odločite se, ali je zahteva storitev ali mehanizem odkrivanja, ker se ta odgovora v stroških razlikujeta za red velikosti. Eden prosi za naslov, ki se ne spreminja; drugi prosi za domeno oddajanja, razširjeno čez povezavo širokega omrežja z vsem, kar iz tega sledi.

Lokalno odkrivanje naj bi se ustavilo

Multicast DNS, opisan v RFC 6762, je zasnovan okoli ene povezave: poizvedbe gredo na fiksno skupino, odgovori se pošiljajo isti skupini, in protokol se zanaša na to, da vsak udeleženec sliši vse. Usmerjevalniki tega prometa privzeto ne posredujejo, in to je oblikovalska odločitev, ne spregled. Meja obstaja zato, da se naprava v eni zgradbi ne more kar tako oglasiti v drugi. Tunel, ki se zdi, da popravi odkrivanje s prenašanjem skupine povsod, je to mejo odstranil za vsako aplikacijo, ne le za tisto, ki je potrebovala pomoč.

Ponavljalniki in odsevniki obstajajo in so resnične storitve z resničnimi posledicami: vsako ime, oglašeno na eni lokaciji, postane vidno na drugi, vključno z imeni naprav, ki identificirajo ljudi ali opremo. Če je resnična zahteva, da je določena storitev najdljiva, je zapis storitve, objavljen v DNS, običajno manjša sprememba in razkrije eno ime namesto toka imen.

Tri stvari, ki jih potrebuje usmerjeni multicast

Usmerjeni multicast potrebuje tri stvari, ki delujejo skupaj: prejemnike, ki se pridružijo skupini, usmerjevalnike, ki zanjo vzdržujejo stanje posredovanja, in tunel, ki naslove skupine obravnava kot promet, ki ga je treba nositi. Tunel s politiko, ki navaja le unicast podomrežja, bo promet skupine spustil na meji šifriranja, zato je prvi simptom pogosto tišina in ne napaka. Vmesnik, ki temelji na poteh, kot je tunel GRE ali VTI, nosi to, kar pošlje vanj usmerjevalna tabela, in to naredi skupino dosegljivo, ko stanje multicasta obstaja.

Dosegljivost vira je druga polovica. Usmerjevalni protokoli multicasta, kot je PIM, gradijo drevesa razdeljevanja s preverjanjem, ali je pot nazaj do vira pričakovana, zato unicast pot, ki kaže drugam, drevo zlomi tudi takrat, ko je članstvo v skupini pravilno. Namestitev poti za prejemnika za to preverjanje ne naredi ničesar, in to je napaka, ki da delujoč ping in neuspešen tok. Najprej preverite povratno pot vira, nato dodajte članstvo in šele nato poglejte aplikacijo.

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

Prvi dve vrstici kažeta, čemu se je gostitelj pridružil in kaj jedro posreduje, tretja kaže članstvo same aplikacije, zadnja pa unicast pot, ki jo bo uporabilo preverjanje povratne poti. Branje skupaj loči aplikacijo, ki se ni nikoli pridružila, od omrežja, ki ni nikoli posredovalo.

Dokažite z enim virom in enim prejemnikom

Preden se dotaknete konfiguracije, potrdite, da aplikacija deluje v enem samem segmentu. Če lokalno spodleti, usmerjanje multicasta ni problem in nobena sprememba tunela ne bo pomagala. Nato ponovite z enim prejemnikom skozi tunel in opazujte pakete na obeh straneh meje šifriranja.

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

Paketi, vidni znotraj tunela, a odsotni zunaj njega, kažejo na kapsuliranje ali politiko; paketi, vidni na obeh straneh brez napredka aplikacije, kažejo na članstvo prejemnika ali vezavo aplikacije. Zajeme naj bodo kratki in filtrirani, ker je širok zajem multicasta na zasedenem segmentu večinoma šum.

Izberite naslov storitve, ko potrebujete le storitev

Odkrivanje obstaja, da najde nekaj, kar se premika. Strežnik s stabilnim imenom ne potrebuje odkrivanja, dokumentiran naslov v zasebnem DNS pa odgovori na resnično uporabnikovo vprašanje brez razširjanja domene oddajanja čez povezavo širokega omrežja. Ista logika velja za tiskalnike, naprave in notranje spletne storitve. Ime v DNS je dosegljivo z vsake lokacije, ki ga potrebuje, medtem ko nič ne oglašuje lokacijam, ki ga ne potrebujejo, in deluje naprej, ko napravo zamenja druga z drugačnim naslovom.

Ko protokol resnično zahteva multicast, ga omejite na skupino in lokacije, ki ga potrebujejo, dokumentirajte zakaj in odločitev ponovno preverite, ko se aplikacija spremeni. Razširiti odkrivanje povsod je enkrat lahko in težko preklicati po letu naprav, ki so tiho odvisne od njega.