Waarom multicast een VPN niet oversteekt zonder plan

Twee locaties kunnen elkaar via unicast perfect bereiken en zich toch gedragen alsof een van beide de ontdekkingsaankondiging van de printer, de IPTV-stream of de hartslag van het cluster niet ziet. Dat is geen kapotte tunnel; het is het verschil tussen een bestemming en een groep. Multicast-bezorging vraagt om een lidmaatschapsmodel, doorstuurstatus langs het pad en een interface die het verkeer wil dragen, en niets daarvan komt uit een unicast-route. Van de groep van de toepassing naar één werkende ontvanger lopen is de kortste weg naar een antwoord.

Begin bij de groep en de toepassing

Vraag welke groepsadres de toepassing gebruikt en waarvoor het verkeer is. Een ontdekkingsprotocol dat diensten aankondigt, een streamingfeed en de hello-pakketten van een routingprotocol zijn drie verschillende problemen met drie verschillende aanvaardbare antwoorden. Het groepsadres zelf zegt het bereik: adressen in het lokale netwerkcontroleblok zijn niet bedoeld om door gewone routing buiten de link te worden doorgestuurd, en toepassingen die ze gebruiken gaan meestal uit van één broadcast-domein. Een streamingfeed op een groep met wereldwijd bereik is een ander ontwerp dan een ontdekkingsprotocol dat verwacht dat elk apparaat elke query hoort, en alleen het tweede geeft om de grootte van het broadcast-domein.

Bepaal of de eis de dienst of het ontdekkingsmechanisme is, want die antwoorden verschillen in kosten met een orde van grootte. Het ene vraagt om een adres dat niet verandert; het andere vraagt om een broadcast-domein dat over een wide-area-link is uitgebreid met alles wat daaruit volgt.

Lokale ontdekking hoort te stoppen

Multicast DNS zoals beschreven in RFC 6762 is ontworpen rond één link: queries gaan naar een vaste groep, antwoorden worden naar dezelfde groep gestuurd, en het protocol vertrouwt erop dat elke deelnemer iedereen hoort. Routers sturen dat verkeer niet standaard door, en dat is een ontwerpbeslissing, geen vergissing. De grens bestaat zodat een apparaat in het ene gebouw zich niet zomaar in het andere kan aankondigen. Een tunnel die ontdekking lijkt te repareren door de groep overal heen te dragen, heeft die grens voor elke toepassing weggehaald, niet alleen voor degene die hulp nodig had.

Repeaters en reflectors bestaan, en het zijn echte diensten met echte gevolgen: elke naam die op de ene locatie wordt aangekondigd, wordt op de andere zichtbaar, inclusief apparaatnamen die mensen of apparatuur identificeren. Als de echte eis is dat een bepaalde dienst vindbaar is, is een in DNS gepubliceerd servicerecord meestal de kleinere wijziging, en het onthult één naam in plaats van een stroom namen.

Drie dingen die gerouteerde multicast nodig heeft

Gerouteerde multicast heeft drie dingen nodig die samenwerken: ontvangers die lid worden van de groep, routers die daarvoor doorstuurstatus bijhouden, en een tunnel die de groepsadressen als te dragen verkeer behandelt. Een tunnel met een beleid dat alleen unicast-subnetten vermeldt, laat het verkeer van de groep bij de versleutelingsgrens vallen, en daarom is het eerste symptoom vaak stilte in plaats van een fout. Een op routes gebaseerde interface, zoals een GRE- of VTI-tunnel, draagt wat de routingtabel erin stuurt, wat de groep bereikbaar maakt zodra de multicast-status bestaat.

Bereikbaarheid van de bron is de tweede helft. Multicast-routingprotocollen zoals PIM bouwen distributiebomen door te controleren of het pad terug naar de bron het verwachte is, dus een unicast-route die ergens anders heen wijst, breekt de boom zelfs wanneer het groepslidmaatschap klopt. Een route voor de ontvanger installeren doet niets voor die controle, en dat is de fout die een werkende ping en een falende stream oplevert. Controleer eerst het terugpad van de bron, voeg daarna het lidmaatschap toe, en kijk pas daarna naar de toepassing.

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

De eerste twee regels laten zien waar de host lid van is geworden en wat de kernel doorstuurt, de derde toont het lidmaatschap van de toepassing zelf, en de laatste het unicast-pad dat de reverse-path-controle gebruikt. Ze samen lezen onderscheidt een toepassing die nooit lid werd van een netwerk dat nooit doorstuurde.

Bewijs het met één bron en één ontvanger

Bevestig voordat u een configuratie aanraakt dat de toepassing op één segment werkt. Als het lokaal mislukt, is multicast-routing niet het probleem en helpt geen enkele tunnelwijziging. Herhaal daarna met één ontvanger door de tunnel en kijk naar de pakketten aan beide zijden van de versleutelingsgrens.

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

Pakketten die binnen de tunnel zichtbaar zijn maar erbuiten ontbreken, wijzen op inkapseling of beleid; pakketten die aan beide zijden zichtbaar zijn zonder vooruitgang in de toepassing, wijzen op het lidmaatschap van de ontvanger of de binding van de toepassing. Houd opnames kort en gefilterd, want een brede multicast-opname op een druk segment is vooral ruis.

Kies een servicadres als u alleen de dienst nodig hebt

Ontdekking bestaat om iets te vinden dat beweegt. Een server met een stabiele naam heeft geen ontdekking nodig, en een gedocumenteerd adres in privé-DNS beantwoordt de echte vraag van de gebruiker zonder een broadcast-domein over een wide-area-link uit te breiden. Dezelfde redenering geldt voor printers, apparaten en interne webservices. Een naam in DNS is bereikbaar vanaf elke locatie die hem nodig heeft terwijl hij niets aankondigt aan de locaties die hem niet nodig hebben, en hij blijft werken wanneer het apparaat wordt vervangen door een met een ander adres.

Wanneer een protocol echt multicast vereist, beperk het dan tot de groep en de locaties die het nodig hebben, documenteer waarom, en herzie de beslissing wanneer de toepassing verandert. Ontdekking overal uitbreiden is één keer makkelijk, en moeilijk terug te draaien na een jaar apparaten die er stil van afhankelijk zijn.