SSM su OpenVPN: seguire una sorgente e un gruppo da capo a fondo

Scegliete un flusso e un ricevitore, poi seguite quella coppia attraverso ogni salto invece di testare il multicast come categoria. Un progetto specifico della sorgente fallisce esattamente in uno di quattro punti: il ricevitore non si è mai unito, il router ha scartato il pacchetto sul percorso inverso, il kernel non ha stato, oppure il tunnel non ha mai consegnato una copia. Lavorare in quest’ordine costa minuti per salto e vi dice quale dei quattro avete davvero.

Fissate prima la sorgente, il gruppo e il ricevitore

Annotate tre valori prima di toccare qualsiasi dispositivo: l’indirizzo sorgente che invierà, l’indirizzo di gruppo a cui si unirà il ricevitore e la sottorete in cui vive il ricevitore. Per un flusso IPv4 illustrativo, una sorgente 10.50.0.10 e un gruppo 232.20.30.40 sono il tipo di coppia che si adatta a un progetto specifico della sorgente. Qualcosa di più vago di quei tre valori non si può testare.

L’intervallo 232/8 è riservato al multicast specifico della sorgente, e il modello è descritto nella RFC 4607. Se il vostro gruppo è fuori da quell’intervallo mentre credete di eseguire SSM, fermatevi e confermate che cosa intende davvero la distribuzione, perché l’adesione del ricevitore e la decisione di inoltro del router dipendono entrambe dalla coerenza del modello.

Verificate che il ricevitore si sia unito alla sorgente

Un rapporto di adesione solo per il gruppo non è un’adesione specifica della sorgente. Chiedete al ricevitore quale sorgente ha richiesto, e sul router del primo salto guardate lo stato del gruppo per vedere se compare un elenco di sorgenti. Se il rapporto non porta alcuna sorgente, il router lo tratterà come un’adesione da qualsiasi sorgente e l’intero progetto degrada in silenzio in qualcosa che non avevate pianificato.

Su un ricevitore Linux, verificate a cosa si è realmente iscritto il socket e cosa ha registrato il kernel. Il file di configurazione dell’applicazione non è una prova; lo è la tabella di adesione. Leggetela mentre il ricevitore è davvero in esecuzione, perché una voce può restare per breve tempo dopo l’uscita del processo che l’ha creata. Una voce obsoleta di un test precedente è una fonte affidabile di falsa sicurezza.

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

Se l’adesione è presente con la sorgente attesa, passate ai router. Se manca, nessuna configurazione del tunnel aiuterà, perché non c’è nulla da inoltrare.

Verificate il percorso inverso prima di guardare il tunnel

L’instradamento multicast esegue un controllo del percorso inverso, e un pacchetto che arriva su un’interfaccia diversa da quella verso cui punta la rotta unicast viene scartato. È il motivo più comune per cui un flusso chiaramente in invio non raggiunge mai il salto successivo, e non produce alcun errore utile a livello applicativo.

Sul router rivolto verso la sorgente, confrontate la rotta verso la sorgente con l’interfaccia su cui i pacchetti arrivano davvero. Sul router rivolto verso il ricevitore, fate lo stesso per la sottorete del ricevitore stesso e confermate che l’elenco delle interfacce in uscita includa il collegamento verso di essa. Una discrepanza in qualsiasi direzione è un guasto RPF, non un guasto di adesione.

Poi confermate che il TTL della sorgente sia abbastanza grande da sopravvivere ai salti instradati che avete progettato. Un flusso che funziona sul primo router e muore sul secondo è spesso una questione di TTL e non di politica.

Leggete lo stato multicast del kernel invece della configurazione

La configurazione vi dice cosa avete chiesto; il kernel vi dice cosa sta succedendo. Su ogni salto Linux, leggete le voci di instradamento multicast e confermate che esista un elenco di interfacce in ingresso e in uscita per la coppia esatta di sorgente e gruppo. Una voce per il gruppo con una sorgente jolly è un oggetto diverso e non spiegherà un flusso specifico della sorgente.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

I demoni di instradamento mantengono una propria visione sopra quello stato, e il comando che la stampa dipende da quale implementazione è installata. Il principio è costante: chiedete al demone la sua voce upstream per la coppia, poi chiedete al kernel se esiste una voce di inoltro. Un demone che crede di inoltrare mentre il kernel non ha alcuna voce è un problema di ambito della configurazione su quell’host.

Quando i due non concordano, riparate l’host e non la VPN. Nulla a valle può compensare un salto che non inoltra il flusso di cui avete chiesto. Annotate la coppia, l’interfaccia in ingresso e l’elenco in uscita per ogni salto mentre il flusso funziona. Quella registrazione trasforma il guasto successivo in un confronto invece che in una nuova indagine.

Decidete come il tunnel replichi davvero

È qui che il multicast su una VPN smette di essere routine. Un tunnel punto a punto consegna un pacchetto all’unico peer dall’altra parte, quindi una copia raggiunge esattamente un client. Un segmento in bridge si comporta più come un collegamento condiviso, perché il tunnel trasporta il frame e il bridge decide cosa inondare. Sono modelli di consegna diversi, e un progetto che presume il secondo mentre esegue il primo sembrerà funzionare per un ricevitore e fallirà per il successivo.

Per più di un ricevitore attraverso un server multipoint, la replica va progettata esplicitamente. Installare una rotta multicast sul gateway non insegna al server VPN quali peer devono ricevere una copia, e nessuna rotta lato client prende quella decisione al suo posto. Dove il requisito è molti ricevitori, usate una replica supportata o un’alternativa scelta deliberatamente, e annotate quale avete scelto.

Infine, verificate sul ricevitore con un’osservazione ristretta: la sorgente, il gruppo e la porta esatti, sull’interfaccia che vi aspettate, mentre un ricevitore autorizzato è unito. SSM seleziona un mittente, e la selezione non è un’autenticazione di quel mittente, né un permesso per altro traffico multicast di attraversare la stessa politica.