Miksi multicast ei ylitä VPN:ää ilman suunnitelmaa

Kaksi toimipistettä voivat tavoittaa toisensa täydellisesti unicastilla ja käyttäytyä silti kuin toinen niistä ei näkisi tulostimen löytöilmoitusta, IPTV-virtaa tai klusterin sydämenlyöntiä. Se ei ole rikki mennyt tunneli; se on ero kohteen ja ryhmän välillä. Multicastin toimitus tarvitsee jäsenyysmallin, edelleenlähetystilan polun varrelle ja rajapinnan, joka on halukas kantamaan liikennettä, eikä mikään niistä tule unicast-reitistä. Siirtyminen sovelluksen ryhmästä yhteen toimivaan vastaanottajaan on lyhin tie vastaukseen.

Aloita ryhmästä ja sovelluksesta

Kysy, mitä ryhmäosoitetta sovellus käyttää ja mitä varten liikenne on. Palveluita ilmoittava löytöprotokolla, suoratoistovirta ja reititysprotokollan hello-paketit ovat kolme eri ongelmaa, joilla on kolme eri hyväksyttävää vastausta. Ryhmäosoite itse kertoo laajuuden: paikallisen verkon ohjauslohkon osoitteita ei ole tarkoitettu tavallisen reitityksen edelleenlähetettäviksi linkin ulkopuolelle, ja niitä käyttävät sovellukset olettavat yleensä yhden lähetysverkkotunnuksen. Globaalin laajuuden ryhmässä oleva suoratoistovirta on eri suunnittelu kuin löytöprotokolla, joka olettaa jokaisen laitteen kuulevan jokaisen kyselyn, ja vain jälkimmäinen välittää lähetysverkkotunnuksen koosta.

Päätä, onko vaatimuksena palvelu vai löytömekanismi, koska nämä vastaukset eroavat kustannuksiltaan suuruusluokan verran. Toinen pyytää osoitetta, joka ei muutu; toinen pyytää laajaverkkolinkin yli ulotettua lähetysverkkotunnusta ja kaiken siitä seuraavan.

Linkin paikallinen löytäminen on tarkoitettu loppumaan

Kohdassa RFC 6762 kuvattu Multicast DNS on suunniteltu yhden linkin ympärille: kyselyt menevät kiinteään ryhmään, vastaukset lähetetään samaan ryhmään ja protokolla luottaa siihen, että jokainen osallistuja kuulee kaikki. Reitittimet eivät välitä tätä liikennettä oletuksena, ja se on suunnittelupäätös eikä huolimattomuus. Raja on olemassa, jotta yhden rakennuksen laite ei voi vain ilmoittautua toiseen. Tunneli, joka näyttää korjaavan löytämisen kuljettamalla ryhmää kaikkialle, on poistanut tämän rajan jokaiselta sovellukselta, ei vain siltä, joka tarvitsi apua.

Toistimet ja heijastimet ovat olemassa, ja ne ovat todellisia palveluita, joilla on todellisia seurauksia: jokainen yhdessä toimipisteessä ilmoitettu nimi tulee näkyväksi toisessa, mukaan lukien laitenimet, jotka tunnistavat ihmisiä tai laitteita. Jos todellinen vaatimus on, että tietty palvelu on löydettävissä, DNS:ään julkaistu palvelutietue on yleensä pienempi muutos, ja se paljastaa yhden nimen niiden virran sijaan.

Kolme asiaa, joita reititetty multicast tarvitsee

Reititetty multicast tarvitsee kolme asiaa, jotka toimivat yhdessä: vastaanottajat, jotka liittyvät ryhmään, reitittimet, jotka ylläpitävät sille edelleenlähetystilaa, ja tunnelin, joka kohtelee ryhmäosoitteita kuljetettavana liikenteenä. Tunneli, jonka käytäntö luettelee vain unicast-aliverkot, pudottaa ryhmän liikenteen salausrajalla, ja siksi ensimmäinen oire on usein hiljaisuus eikä virhe. Reittipohjainen rajapinta, kuten GRE- tai VTI-tunneli, kuljettaa sen, mitä reititystaulu lähettää siihen, mikä tekee ryhmästä tavoitettavan, kun multicast-tila on olemassa.

Lähteen tavoitettavuus on toinen puoli. Multicast-reititysprotokollat kuten PIM rakentavat jakelupuut tarkistamalla, että paluupolku lähteeseen on odotettu, joten muualle osoittava unicast-reitti rikkoo puun, vaikka ryhmän jäsenyys olisi oikein. Vastaanottajalle asennettava reitti ei tee tälle tarkistukselle mitään, ja se on virhe, joka tuottaa toimivan pingin ja epäonnistuvan virran. Tarkista ensin lähteen paluupolku, lisää sitten jäsenyys ja katso sovellusta vasta sen jälkeen.

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

Kaksi ensimmäistä riviä näyttävät, mihin isäntä on liittynyt ja mitä ydin välittää, kolmas näyttää sovelluksen oman jäsenyyden ja viimeinen unicast-polun, jota käänteisen polun tarkistus käyttää. Niiden lukeminen yhdessä erottaa sovelluksen, joka ei koskaan liittynyt, verkosta, joka ei koskaan välittänyt.

Todista se yhdellä lähteellä ja yhdellä vastaanottajalla

Ennen kuin kosket asetukseen, varmista, että sovellus toimii yhdessä segmentissä. Jos se epäonnistuu paikallisesti, multicast-reititys ei ole ongelma eikä mikään tunnelimuutos auta. Toista sitten yhdellä vastaanottajalla tunnelin yli ja seuraa paketteja salausrajan molemmilla puolilla.

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

Tunnelin sisällä näkyvät mutta sen ulkopuolella puuttuvat paketit viittaavat kapselointiin tai käytäntöön; molemmilla puolilla näkyvät paketit ilman sovelluksen edistymistä viittaavat vastaanottajan jäsenyyteen tai sovelluksen sidontaan. Pidä tallenteet lyhyinä ja suodatettuina, sillä laaja multicast-tallenne vilkkaassa segmentissä on pääosin kohinaa.

Suosi palveluosoitetta, kun tarvitset vain palvelun

Löytäminen on olemassa sitä varten, että löydetään jotain, joka liikkuu. Vakaannimisellä palvelimella ei ole löytämisen tarvetta, ja yksityisessä DNS:ssä dokumentoitu osoite vastaa käyttäjän todelliseen kysymykseen ulottamatta lähetysverkkotunnusta laajaverkkolinkin yli. Sama päättely pätee tulostimiin, laitteisiin ja sisäisiin verkkopalveluihin. DNS:n nimi on tavoitettavissa jokaisesta toimipisteestä, joka sitä tarvitsee, ilmoittamatta mitään niille, jotka eivät tarvitse, ja se toimii edelleen, kun laite korvataan toisella, jolla on eri osoite.

Kun protokolla todella vaatii multicastia, rajaa se ryhmään ja toimipisteisiin, jotka sitä tarvitsevat, dokumentoi miksi ja tarkastele päätöstä uudelleen, kun sovellus muuttuu. Löytämisen ulottaminen kaikkialle on helppo tehdä kerran ja vaikea perua, kun laitteet ovat vuoden ajan hiljaa riippuneet siitä.