SSM sobre OpenVPN: seguir una font i un grup de cap a cap

Triï un flux i un receptor, i després segueixi aquesta parella per cada salt en lloc de provar el multicast com una categoria. Un disseny específic de font falla exactament en un de quatre llocs: el receptor no s’hi va unir mai, l’encaminador va rebutjar el paquet en el camí invers, el nucli no té estat, o el túnel no va lliurar mai cap còpia. Treballar en aquest ordre costa minuts per salt i us diu quin dels quatre teniu realment.

Fixe la font, el grup i el receptor primer

Anoti tres valors abans de tocar cap dispositiu: l’adreça d’origen que enviarà, l’adreça de grup a què s’unirà el receptor i la subxarxa on viu el receptor. Per a un flux IPv4 il·lustratiu, una font 10.50.0.10 i un grup 232.20.30.40 són el tipus de parella que encaixa en un disseny específic de font. Qualsevol cosa més vaga que aquests tres valors no es pot provar.

El rang 232/8 està reservat per al multicast específic de font, i el model es descriu a RFC 4607. Si el vostre grup és fora d’aquest rang mentre creieu que feu servir SSM, atureu-vos i confirmeu què pretén realment el desplegament, perquè l’adhesió del receptor i la decisió de reenviament de l’encaminador depenen totes dues que el model sigui coherent.

Comproveu que el receptor s’hagi unit a la font

Un informe d’adhesió només per al grup no és una adhesió específica de font. Pregunteu al receptor quina font ha demanat i, a l’encaminador del primer salt, mireu l’estat del grup per veure si hi apareix una llista de fonts. Si l’informe no porta cap font, l’encaminador el tractarà com una adhesió a qualsevol font i tot el disseny es degrada en silenci cap a una cosa que no havíeu planificat.

En un receptor Linux, comproveu a què s’ha subscrit realment el sòcol i què ha registrat el nucli. El fitxer de configuració de l’aplicació no és una prova; la taula d’adhesió sí que ho és. Llegiu-la mentre el receptor s’executa de debò, perquè una entrada pot perdurar una estona després que surti el procés que la va crear. Una entrada obsoleta d’una prova anterior és una font fiable de falsa confiança.

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

Si l’adhesió hi és amb la font esperada, passeu als encaminadors. Si hi falta, cap configuració de túnel no ajudarà, perquè no hi ha res per reenviar.

Verifiqueu el camí invers abans de mirar el túnel

L’encaminament multicast fa una comprovació del camí invers, i un paquet que arriba per una interfície diferent de la que indica la ruta unicast es descarta. És el motiu més habitual que un flux que clarament s’envia no arribi mai al salt següent, i no produeix cap error útil a nivell d’aplicació.

A l’encaminador que mira cap a la font, compareu la ruta cap a la font amb la interfície per la qual arriben realment els paquets. A l’encaminador que mira cap al receptor, feu el mateix per a la subxarxa pròpia del receptor i confirmeu que la llista d’interfícies de sortida inclou l’enllaç cap a ella. Una discrepància en qualsevol direcció és un error d’RPF, no un error d’adhesió.

Després confirmeu que el TTL de la font és prou gran per sobreviure als salts encaminats que heu dissenyat. Un flux que funciona al primer encaminador i mor al segon sovint és una qüestió de TTL i no de política.

Llegiu l’estat multicast del nucli en lloc de la configuració

La configuració us diu què heu demanat; el nucli us diu què passa. A cada salt Linux, llegiu les entrades d’encaminament multicast i confirmeu que existeix una llista d’interfícies d’entrada i de sortida per a la parella exacta de font i grup. Una entrada per al grup amb una font comodí és un objecte diferent i no explicarà un flux específic de font.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Els dimonis d’encaminament mantenen la seva pròpia visió sobre aquest estat, i l’ordre que la imprimeix depèn de quina implementació hi hagi instal·lada. El principi és constant: pregunteu al dimoni per la seva entrada upstream per a la parella i després pregunteu al nucli si existeix una entrada de reenviament. Un dimoni que creu que reenvia mentre el nucli no té entrada és un problema d’abast de configuració en aquell amfitrió.

Quan els dos no coincideixen, arregleu l’amfitrió i no la VPN. Res aigües avall no pot compensar un salt que no reenvia el flux que heu demanat. Anoteu la parella, la interfície d’entrada i la llista de sortida per a cada salt mentre el flux funciona. Aquest registre converteix la propera fallada en una comparació en lloc d’una investigació nova.

Decidiu com replica realment el túnel

Aquí és on el multicast sobre una VPN deixa de ser rutinari. Un túnel punt a punt lliura un paquet a l’únic igual a l’altre extrem, així que una còpia arriba exactament a un client. Un segment pontat es comporta més aviat com un enllaç compartit, perquè el túnel transporta la trama i el pont decideix què inunda. Són models d’entrega diferents, i un disseny que assumeix el segon mentre funciona amb el primer semblarà correcte per a un receptor i fallarà per al següent.

Per a més d’un receptor a través d’un servidor multipunt, la replicació s’ha de dissenyar explícitament. Instal·lar una ruta multicast a la passarel·la no ensenya al servidor VPN quins iguals han de rebre una còpia, i cap ruta del costat client pren aquesta decisió per ell. Quan el requisit és tenir molts receptors, feu servir replicació suportada o una alternativa triada deliberadament, i anoteu quina heu triat.

Finalment, verifiqueu al receptor amb una observació estreta: la font, el grup i el port exactes, a la interfície que espereu, mentre un receptor autoritzat hi és unit. SSM selecciona un remitent, i la selecció no és autenticació d’aquest remitent ni permís perquè altre trànsit multicast travessi la mateixa política.