SSM sobre OpenVPN: seguir uma fonte e um grupo de ponta a ponta

Escolha um fluxo e um recetor e depois siga esse par por cada salto em vez de testar o multicast como uma categoria. Um desenho específico de fonte falha exatamente num de quatro lugares: o recetor nunca se juntou, o router rejeitou o pacote no caminho inverso, o kernel não tem estado, ou o túnel nunca entregou uma cópia. Trabalhar nessa ordem custa minutos por salto e diz-lhe qual dos quatro tem realmente.

Fixe primeiro a fonte, o grupo e o recetor

Anote três valores antes de tocar em qualquer dispositivo: o endereço de origem que vai enviar, o endereço de grupo a que o recetor se vai juntar e a sub-rede onde o recetor vive. Para um fluxo IPv4 ilustrativo, uma fonte 10.50.0.10 e um grupo 232.20.30.40 são o tipo de par que assenta num desenho específico de fonte. Nada mais vago do que esses três valores pode ser testado.

O intervalo 232/8 está reservado para multicast específico de fonte, e o modelo está descrito no RFC 4607. Se o seu grupo estiver fora desse intervalo enquanto acredita que executa SSM, pare e confirme o que o desdobramento realmente pretende, porque a adesão do recetor e a decisão de encaminhamento do router dependem ambas de o modelo ser consistente.

Verifique se o recetor se juntou à fonte

Um relatório de adesão apenas para o grupo não é uma adesão específica de fonte. Pergunte ao recetor que fonte pediu, e no router do primeiro salto olhe para o estado do grupo para ver se aparece uma lista de fontes. Se o relatório não transportar fonte, o router tratá-lo-á como uma adesão a qualquer fonte e todo o desenho degrada-se em silêncio para algo que não planificou.

Num recetor Linux, verifique a que se subscreveu realmente o socket e o que o kernel registou. O ficheiro de configuração da aplicação não é prova; a tabela de adesão é. Leia-a enquanto o recetor está realmente em execução, porque uma entrada pode persistir brevemente depois de sair o processo que a criou. Uma entrada antiga de um teste anterior é uma fonte fiável de falsa confiança.

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

Se a adesão estiver presente com a fonte esperada, passe aos routers. Se faltar, nenhuma configuração de túnel ajudará, porque não há nada para encaminhar.

Verifique o caminho inverso antes de olhar para o túnel

O encaminhamento multicast efetua uma verificação do caminho inverso, e um pacote que chega por uma interface diferente daquela para onde aponta a rota unicast é descartado. É a razão mais comum pela qual um fluxo que está claramente a ser enviado nunca chega ao salto seguinte, e não produz qualquer erro útil ao nível da aplicação.

No router virado para a fonte, compare a rota para a fonte com a interface por onde os pacotes chegam realmente. No router virado para o recetor, faça o mesmo para a sub-rede do próprio recetor e confirme que a lista de interfaces de saída inclui a ligação até ela. Uma discrepância em qualquer direção é uma falha de RPF, não uma falha de adesão.

Depois confirme que o TTL da fonte é suficientemente grande para sobreviver aos saltos encaminhados que desenhou. Um fluxo que funciona no primeiro router e morre no segundo é muitas vezes uma questão de TTL e não de política.

Leia o estado multicast do kernel em vez da configuração

A configuração diz-lhe o que pediu; o kernel diz-lhe o que está a acontecer. Em cada salto Linux, leia as entradas de encaminhamento multicast e confirme que existe uma lista de interfaces de entrada e de saída para o par exato de fonte e grupo. Uma entrada para o grupo com uma fonte universal é um objeto diferente e não explicará um 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 encaminhamento mantêm a sua própria visão sobre esse estado, e o comando que a imprime depende de que implementação está instalada. O princípio é constante: pergunte ao daemon pela sua entrada a montante para o par e depois pergunte ao kernel se existe uma entrada de encaminhamento. Um daemon que pensa que está a encaminhar enquanto o kernel não tem entrada é um problema de âmbito de configuração nesse host.

Quando os dois não concordam, corrija o host e não a VPN. Nada a jusante pode compensar um salto que não encaminha o fluxo sobre o qual perguntou. Registe o par, a interface de entrada e a lista de saída para cada salto enquanto o fluxo funciona. Esse registo transforma a falha seguinte numa comparação em vez de uma nova investigação.

Decida como o túnel replica realmente

É aqui que o multicast sobre uma VPN deixa de ser rotina. Um túnel ponto a ponto entrega um pacote ao único par do outro lado, pelo que uma cópia chega exatamente a um cliente. Um segmento ligado por ponte comporta-se mais como uma ligação partilhada, porque o túnel transporta a trama e a ponte decide o que inundar. São modelos de entrega diferentes, e um desenho que assume o segundo enquanto executa o primeiro parecerá funcionar para um recetor e falhará para o seguinte.

Para mais do que um recetor através de um servidor multiponto, a replicação tem de ser desenhada explicitamente. Instalar uma rota multicast no gateway não ensina ao servidor VPN quais pares devem receber uma cópia, e nenhuma rota do lado do cliente toma essa decisão por ele. Onde o requisito é muitos recetores, use replicação suportada ou uma alternativa escolhida deliberadamente, e registe qual escolheu.

Por fim, verifique no recetor com uma observação estreita: a fonte, o grupo e a porta exatos, na interface que espera, enquanto um recetor autorizado está ligado. O SSM seleciona um remetente, e a seleção não é autenticação desse remetente, nem permissão para outro tráfego multicast atravessar a mesma política.