SSM sobre OpenVPN: seguir unha fonte e un grupo de principio a fin

Escolla un fluxo e un receptor, e despois siga ese par por cada salto en lugar de probar o multicast como unha categoría. Un deseño específico de fonte falla exactamente nun de catro lugares: o receptor nunca se uniu, o encamiñador rexeitou o paquete na súa ruta inversa, o núcleo non ten estado, ou o túnel nunca entregou unha copia. Traballar nesa orde custa minutos por salto e dille cal dos catro ten realmente.

Fixe primeiro a fonte, o grupo e o receptor

Anote tres valores antes de tocar calquera dispositivo: o enderezo de orixe que enviará, o enderezo de grupo ao que se unirá o receptor e a subrede na que vive o receptor. Para un fluxo IPv4 ilustrativo, unha fonte 10.50.0.10 e un grupo 232.20.30.40 son o tipo de par que encaixa nun deseño específico de fonte. Calquera cousa máis vaga que eses tres valores non se pode probar.

O rango 232/8 está reservado para multicast específico de fonte, e o modelo descríbese en RFC 4607. Se o seu grupo está fóra dese rango mentres cre que executa SSM, detéñase e confirme que pretende realmente o despregamento, porque a adhesión do receptor e a decisión de reenvío do encamiñador dependen ambas de que o modelo sexa coherente.

Comprobe que o receptor se uniu á fonte

Un informe de adhesión só para o grupo non é unha adhesión específica de fonte. Pregunte ao receptor que fonte solicitou, e no encamiñador do primeiro salto mire o estado do grupo para ver se aparece unha lista de fontes. Se o informe non leva ningunha fonte, o encamiñador trataráo como unha adhesión a calquera fonte e todo o deseño degrádase en silencio cara a algo que non planificara.

Nun receptor Linux, comprobe a que se subscribiu realmente o socket e que rexistrou o núcleo. O ficheiro de configuración da aplicación non é unha proba; a táboa de adhesión si o é. Léaa mentres o receptor está realmente en execución, porque unha entrada pode persistir brevemente despois de que saia o proceso que a creou. Unha entrada obsoleta dunha proba anterior é unha fonte fiable de falsa confianza.

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

Se a adhesión está presente coa fonte esperada, pase aos encamiñadores. Se falta, ningunha configuración de túnel axudará, porque non hai nada que reenviar.

Verifique a ruta inversa antes de mirar o túnel

O encamiñamento multicast realiza unha comprobación de ruta inversa, e un paquete que chega por unha interface distinta da que indica a ruta unicast descártase. É a razón máis común pola que un fluxo que claramente se está a enviar nunca chega ao seguinte salto, e non produce ningún erro útil a nivel de aplicación.

No encamiñador que mira cara á fonte, compare a ruta cara á fonte coa interface pola que chegan realmente os paquetes. No encamiñador que mira cara ao receptor, faga o mesmo para a subrede propia do receptor e confirme que a lista de interfaces de saída inclúe a ligazón cara a ela. Unha discrepancia en calquera dirección é un fallo de RPF, non un fallo de adhesión.

Despois confirme que o TTL da fonte é o bastante grande para sobrevivir aos saltos encamiñados que deseñou. Un fluxo que funciona no primeiro encamiñador e morre no segundo adoita ser unha cuestión de TTL e non de política.

Lea o estado multicast do núcleo en lugar da configuración

A configuración dille o que pediu; o núcleo dille o que ocorre. En cada salto Linux, lea as entradas de encamiñamento multicast e confirme que existe unha lista de interfaces de entrada e de saída para o par exacto de fonte e grupo. Unha entrada para o grupo cunha fonte comodín é un obxecto distinto e non explicará un fluxo específico de fonte.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

Os daemons de encamiñamento manteñen a súa propia visión sobre ese estado, e o comando que a imprime depende de que implementación estea instalada. O principio é constante: pregunte ao daemon pola súa entrada upstream para o par e despois pregunte ao núcleo se existe unha entrada de reenvío. Un daemon que cre que reenvía mentres o núcleo non ten entrada é un problema de alcance de configuración nese host.

Cando os dous non coinciden, arranxe o host e non a VPN. Nada augas abaixo pode compensar un salto que non reenvía o fluxo polo que preguntou. Anote o par, a interface de entrada e a lista de saída para cada salto mentres o fluxo funciona. Ese rexistro converte o seguinte fallo nunha comparación en lugar dunha investigación nova.

Decida como replica realmente o túnel

Aquí é onde o multicast sobre unha VPN deixa de ser rutineiro. Un túnel punto a punto entrega un paquete ao único par do outro extremo, así que unha copia chega exactamente a un cliente. Un segmento ponteado compórtase máis ben como unha ligazón compartida, porque o túnel transporta a trama e a ponte decide que inundar. Son modelos de entrega distintos, e un deseño que asume o segundo mentres executa o primeiro parecerá funcionar para un receptor e fallará para o seguinte.

Para máis dun receptor a través dun servidor multipunto, a replicación debe deseñarse explicitamente. Instalar unha ruta multicast na pasarela non lle ensina ao servidor VPN que pares deben recibir unha copia, e ningunha ruta do lado do cliente toma esa decisión por el. Onde o requisito é moitos receptores, use replicación soportada ou unha alternativa escollida deliberadamente, e anote cal escolleu.

Por último, verifique no receptor cunha observación estreita: a fonte, o grupo e o porto exactos, na interface que espera, mentres un receptor autorizado está unido. SSM selecciona un remitente, e a selección non é autenticación dese remitente nin permiso para que outro tráfico multicast cruce a mesma política.