Perché la scoperta dei vicini IPv6 fallisce attraverso una VPN instradata

La scoperta dei vicini IPv6 appartiene a un collegamento, e un tunnel instradato è un confine tra due collegamenti. Quella singola frase spiega quasi ogni segnalazione di un host remoto che risponde per indirizzo e non si trova in nessun altro modo. Controlla l’ambito dell’indirizzo che stai testando prima di controllare il tunnel. Un indirizzo locale al collegamento ha senso solo sul proprio collegamento, e un gruppo multicast del nodo richiesto è limitato allo stesso modo. Nessuno dei due attraversa un router, ed è per questo che un ping verso un indirizzo globale può riuscire mentre la scoperta per lo stesso host no.

L’ambito viene prima della configurazione

La richiesta e l’annuncio di vicino portano un limite di salti di 255 e non vengono inoltrati, per progetto. Il router tra il tuo tunnel e la LAN remota inoltra i pacchetti IPv6 e non ritrasmette i messaggi dei vicini per suo conto. Così la cache dei vicini sull’interfaccia del tunnel contiene il peer e poco altro, che è un comportamento corretto e non un difetto da correggere.

Un indirizzo locale al collegamento come una voce fe80:: è anche limitato alla zona, e lo stesso testo può indicare un host diverso su un altro collegamento. Testarne uno dall’altro lato del tunnel non dimostra nulla se non che l’indirizzo è ambiguo.

La trappola è l’ipotesi che il prefisso sia sul collegamento

Un host che crede che un prefisso sia sul collegamento invia una richiesta di vicino invece di consegnare il pacchetto al suo router, e questo vale anche per un /64 instradato verso un sito remoto. Quando un tale prefisso arriva come sul collegamento, l’host chiede al collegamento locale un host che vive altrove, e nulla risponde. Instrada qualcosa di più piccolo verso l’host remoto, oppure termina il prefisso sul router che risponderà per lui.

Un /128 per un singolo servizio è la disposizione meno sorprendente, ed elimina del tutto l’ambiguità. La specifica della scoperta dei vicini descrive l’insieme dei messaggi e il flag sul collegamento che decide la questione.

Il bridging cambia le regole di proposito

Quando il tunnel trasporta frame Ethernet, i segmenti remoto e locale diventano un unico collegamento, il multicast raggiunge entrambi i lati e la scoperta dei vicini si comporta come su uno switch. Le conseguenze arrivano con esso: inondazione di broadcast e multicast, rilevamento di indirizzi duplicati attraverso il bridge e annunci del router che filtrano in un segmento che non dovrebbe vederli. Il dominio di guasto ora comprende anche due siti. Nulla di ciò depone contro il bridging, e ogni punto è una ragione per fare bridging deliberatamente e non incidentalmente.

Passare un profilo da TUN a TAP per far comparire la scoperta è l’ordine sbagliato delle operazioni. Server, client e piano di indirizzamento devono essere d’accordo, e i client mobili non offrono affatto un’interfaccia TAP, quindi un tale progetto funziona su un portatile e fallisce su un telefono. I proxy e i relay dei vicini sono meccanismi separati con requisiti propri, e appartengono alla disposizione documentata dell’amministratore di rete e non alle impostazioni di un’applicazione.

Prova con l’indirizzo che usa l’applicazione

Conferma la rotta con ip -6 route get, ispeziona la voce del vicino con ip -6 neigh, poi conferma il servizio sul percorso instradato. DNS e percorso di ritorno sono controlli separati, e una voce di vicino sana non dimostra nessuno dei due.

Se l’applicazione insiste su una destinazione locale al collegamento o basata sulla scoperta, è una conversazione di progetto e non un esercizio di tuning, perché nessuna impostazione del client rende funzionante un meccanismo limitato al collegamento attraverso un router.

Annota quale progetto hai

Registra se è instradato o con bridge prima dell’incidente, perché i due dispiegamenti rispondono a queste domande in modo diverso e un ingegnere di turno non dovrebbe dedurlo da un profilo.

Leggere una volta l’insieme dei messaggi toglie la tentazione di spiegare una proprietà di ambito di collegamento come un bug della VPN, che è la diagnosi errata più costosa in questo settore.