Waarom multicast nie 'n VPN sonder 'n plan oorsteek nie

Twee persele kan mekaar perfek per unicast bereik en tog optree asof een van hulle nie die drukker se ontdekkingsaankondiging, die IPTV-stroom of die groep se hartklop kan sien nie. Dit is nie 'n gebreekte tonnel nie; dit is die verskil tussen 'n bestemming en 'n groep. Multicast-aflewering benodig 'n lidmaatskapmodel, aanstuurtoestand langs die pad en 'n koppelvlak wat bereid is om die verkeer te dra, en nie een daarvan kom uit 'n unicast-roete nie. Om van die toepassing se groep na een werkende ontvanger te stap, is die kortste pad na 'n antwoord.

Begin met die groep en die toepassing

Vra watter groepadres die toepassing gebruik en waarvoor die verkeer is. 'n Ontdekkingsprotokol wat dienste aankondig, 'n stromende voer en die hallo-pakkette van 'n roeteringsprotokol is drie verskillende probleme met drie verskillende aanvaarbare antwoorde. Die groepadres self vertel jou die omvang: adresse in die plaaslike netwerkbeheerblok is nie bedoel om deur gewone roetering van die skakel af aangestuur te word nie, en toepassings wat hulle gebruik, neem gewoonlik 'n enkele uitsaaidomein aan. 'n Stromende voer op 'n groep met globale omvang is 'n ander ontwerp as 'n ontdekkingsprotokol wat verwag dat elke toestel elke navraag moet hoor, en net die tweede een gee om oor die grootte van die uitsaaidomein.

Besluit of die vereiste die diens of die ontdekkingsmeganisme is, want daardie antwoorde verskil in koste met 'n orde van grootte. Die een vra vir 'n adres wat nie verander nie; die ander vra vir 'n uitsaaidomein wat oor 'n wyearaaiskakel uitgebrei word met alles wat daaruit volg.

Skakel-plaaslike ontdekking is veronderstel om te stop

Multicast-DNS soos beskryf in RFC 6762 is rondom 'n enkele skakel ontwerp: navrae gaan na 'n vaste groep, antwoorde word na dieselfde groep gestuur, en die protokol maak staat daarop dat elke deelnemer almal hoor. Roeteerders stuur daardie verkeer nie by verstek aan nie, en dit is 'n ontwerpbesluit eerder as 'n versuim. Die grens bestaan sodat 'n toestel in een gebou hom nie sommer in 'n ander een kan aankondig nie. 'n Tonnel wat ontdekking blykbaar regmaak deur die groep oral heen te dra, het daardie grens vir elke toepassing verwyder, nie net vir die een wat hulp nodig gehad het nie.

Herhalers en refleksies bestaan, en dit is werklike dienste met werklike gevolge: elke naam wat by een perseel aangekondig word, word by die ander sigbaar, insluitend toestelname wat mense of toerusting identifiseer. As die werklike vereiste is dat 'n spesifieke diens vindbaar moet wees, is 'n diensrekord wat in DNS gepubliseer word gewoonlik die kleiner verandering, en dit openbaar een naam in plaas van 'n stroom daarvan.

Drie dinge wat gerouteerde multicast nodig het

Gerouteerde multicast benodig drie dinge wat saamwerk: ontvangers wat by die groep aansluit, roeteerders wat aanstuurtoestand daarvoor onderhou, en 'n tonnel wat die groepadresse as verkeer hanteer om te dra. 'n Tonnel met 'n beleid wat net unicast-subnette lys, sal die groepverkeer by die enkripsiegrens laat val, en daarom is die eerste simptoom dikwels stilte eerder as 'n fout. 'n Roetegebaseerde koppelvlak soos 'n GRE- of VTI-tonnel dra wat die roetertabel ook al daarin stuur, wat die groep bereikbaar maak sodra die multicast-toestand bestaan.

Bronbereikbaarheid is die tweede helfte. Multicast-roeteringsprotokolle soos PIM bou verspreidingsbome deur te kontroleer dat die pad terug na die bron die verwagte een is, so 'n unicast-roete wat elders heen wys, breek die boom selfs wanneer die groepildmaatskap korrek is. Om 'n roete vir die ontvanger te installeer, doen niks vir daardie kontrole nie, en dit is die fout wat 'n werkende ping en 'n mislukkende stroom lewer. Verifieer eers die bron se terugpad, voeg dan lidmaatskap by, en kyk eers daarna na die toepassing.

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

Die eerste twee reels wys waartoe die gasheer aangesluit het en wat die kernel aanstuur, die derde wys die toepassing se eie lidmaatskap, en die laaste wys die unicast-pad wat die omgekeerde-pad-kontrole sal gebruik. Om hulle saam te lees, onderskei 'n toepassing wat nooit aangesluit het nie van 'n netwerk wat nooit aangestuur het nie.

Bewys dit met een bron en een ontvanger

Voordat jy 'n konfigurasie aanraak, bevestig dat die toepassing op 'n enkele segment werk. As dit plaaslik misluk, is multicast-roetering nie die probleem nie en sal geen tonnelverandering help nie. Herhaal dan met een ontvanger oor die tonnel en kyk na die pakkette aan beide kante van die enkripsiegrens.

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

Pakkette wat binne die tonnel sigbaar is maar daarbuite afwesig is, wys op enkapsulering of beleid; pakkette wat aan beide kante sigbaar is sonder toepassingsvordering wys op die ontvanger se lidmaatskap of die toepassing se binding. Hou opnames kort en gefiltreer, want 'n bree multicast-opname op 'n besige segment is meestal geraas.

Verkies 'n diensadres wanneer jy net die diens nodig het

Ontdekking bestaan om iets te vind wat beweeg. 'n Bediener met 'n stabiele naam het nie ontdekking nodig nie, en 'n gedokumenteerde adres in private DNS beantwoord die gebruiker se werklike vraag sonder om 'n uitsaaidomein oor 'n wyearaaiskakel uit te brei. Dieselfde redenasie geld vir drukkers, toestelle en interne webdienste. 'n Naam in DNS is bereikbaar van elke perseel wat dit nodig het terwyl dit niks aan die persele aankondig wat dit nie nodig het nie, en dit bly werk wanneer die toestel deur een met 'n ander adres vervang word.

Wanneer 'n protokol werklik multicast vereis, beperk dit tot die groep en die persele wat dit nodig het, dokumenteer waarom, en hersien die besluit wanneer die toepassing verander. Om ontdekking oral uit te brei is maklik om een keer te doen, en moeilik om terug te draai na 'n jaar van toestelle wat stilweg daarop staatmaak.