Miks multicast ei ületa VPN-i ilma plaanita

Kaks asukohta võivad unicasti kaudu teineteist ideaalselt kätte saada ja käituda siiski nii, nagu üks neist ei näeks printeri avastusteate, IPTV voo ega klastri südametukse. See ei ole katkine tunnel; see on erinevus sihtkoha ja grupi vahel. Multicasti edastamine nõuab liikmelisuse mudelit, edastusolekut mööda teed ja liidest, mis on nõus liiklust kandma, ja ükski neist ei tule unicast-marsruudilt. Liikumine rakenduse grupist ühe töötava vastuvõtjani on lühim tee vastuseni.

Alustage grupist ja rakendusest

Küsige, millist grupi aadressi rakendus kasutab ja milleks liiklus on. Teeneid kuulutav avastusprotokoll, voogedastusvoog ja marsruutimisprotokolli tere-paketid on kolm erinevat probleemi kolme erineva vastuvõetava vastusega. Grupi aadress ise ütleb ulatuse: kohaliku võrgu juhtploki aadressid ei ole mõeldud tavalise marsruutimisega lingilt edasi saatmiseks ja neid kasutavad rakendused eeldavad tavaliselt üht ringhäälingudomeeni. Ülemaailmse ulatusega grupi voogedastusvoog on teistsugune lahendus kui avastusprotokoll, mis eeldab, et iga seade kuuleb iga päringut, ja ainult teine hoolib ringhäälingudomeeni suurusest.

Otsustage, kas nõue on teenus või avastusmehhanism, sest need vastused erinevad kulult suurusjärgu võrra. Üks palub aadressi, mis ei muutu; teine palub ringhäälingudomeeni, mis on laiendatud üle laivõrgu lingi koos kõige sellest tulenevaga.

Lingi-kohalik avastus peab lõppema

RFC 6762-s kirjeldatud Multicast DNS on loodud ühe lingi ümber: päringud lähevad kindlale grupile, vastused saadetakse samale grupile ja protokoll loodab, et iga osaleja kuuleb kõiki. Marsruuterid ei edasta seda liiklust vaikimisi ja see on disainiotsus, mitte tähelepanematus. Piir on olemas selleks, et ühe hoone seade ei saaks end teise hoone omale lihtsalt kuulutada. Tunnel, mis näib avastuse parandavat, kandes gruppi kõikjale, on selle piiri eemaldanud iga rakenduse jaoks, mitte ainult selle jaoks, mis abi vajas.

Kordajad ja peegeldajad on olemas ja need on tõelised teenused tõeliste tagajärgedega: iga ühes asukohas kuulutatud nimi muutub teises nähtavaks, sealhulgas seadmenimed, mis identifitseerivad inimesi või seadmeid. Kui tegelik nõue on, et konkreetne teenus oleks leitav, on DNS-is avaldatud teenusekirje tavaliselt väiksem muudatus ja see avalikustab ühe nime, mitte nende voo.

Kolm asja, mida marsruuditud multicast vajab

Marsruuditud multicast vajab kolme asja koos töötamas: vastuvõtjaid, kes grupiga liituvad, marsruutereid, kes selle jaoks edastusolekut hoiavad, ja tunnelit, mis kohtleb grupi aadresse kantava liiklusena. Tunnel, mille poliitika loetleb ainult unicast-alavõrgud, pillab grupi liikluse krüpteerimispiiril maha, mistõttu on esimene sümptom sageli vaikus, mitte viga. Marsruudipõhine liides, näiteks GRE või VTI tunnel, kannab seda, mida marsruutimistabel sinna saadab, mis teeb grupi kättesaadavaks, kui multicast-olek on olemas.

Allika kättesaadavus on teine pool. Multicasti marsruutimisprotokollid nagu PIM ehitavad jaotuspuud, kontrollides, et tee tagasi allikani on oodatav, seega mujale osutav unicast-marsruut lõhub puu ka siis, kui grupiliikmelisus on õige. Vastuvõtja jaoks marsruudi paigaldamine ei tee selle kontrolli jaoks midagi ja see on viga, mis annab töötava pingi ja ebaõnnestuva voo. Kontrollige esmalt allika tagasiteed, seejärel lisage liikmelisus ja alles siis vaadake rakendust.

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

Kaks esimest rida näitavad, millega host liitus ja mida tuum edastab, kolmas näitab rakenduse enda liikmelisust ja viimane unicast-teed, mida pöördtee kontroll kasutab. Nende koos lugemine eristab rakendust, mis ei liitunud kunagi, võrgust, mis ei edastanud kunagi.

Tõestage seda ühe allika ja ühe vastuvõtjaga

Enne konfiguratsiooni puutumist veenduge, et rakendus töötab ühes segmendis. Kui see kohapeal ebaõnnestub, ei ole multicast-marsruutimine probleem ja ükski tunneli muudatus ei aita. Seejärel korrake ühe vastuvõtjaga üle tunneli ja jälgige pakette krüpteerimispiiri mõlemal küljel.

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

Tunneli sees nähtavad, kuid väljaspool puuduvad paketid viitavad kapseldamisele või poliitikale; mõlemal pool nähtavad paketid ilma rakenduse edenemiseta viitavad vastuvõtja liikmelisusele või rakenduse sidumisele. Hoidke salvestised lühikesed ja filtreeritud, sest lai multicast-salvestis hõivatud segmendis on peamiselt müra.

Eelistage teenuse aadressi, kui vajate ainult teenust

Avastus on olemas selleks, et leida midagi, mis liigub. Stabiilse nimega server ei vaja avastust ja privaatses DNS-is dokumenteeritud aadress vastab kasutaja tegelikule küsimusele, laiendamata ringhäälingudomeeni üle laivõrgu lingi. Sama loogika kehtib printerite, seadmete ja sisemiste veebiteenuste kohta. DNS-is olev nimi on kättesaadav igast asukohast, mis seda vajab, samas ei kuuluta see midagi asukohtadele, mis ei vaja, ja see jätkab töötamist, kui seade asendatakse teise, erineva aadressiga seadmega.

Kui protokoll tõesti nõuab multicast'i, piiritle see grupi ja asukohtadega, mis seda vajavad, dokumenteeri miks, ja vaata otsus uuesti üle, kui rakendus muutub. Avastuse laiendamine kõikjale on üks kord lihtne ja pärast aastat seadmeid, mis sellest vaikselt sõltuvad, raske tagasi pöörata.