Impostazioni punchy di Nebula: quale risolve il tuo NAT

Due peer si trovano attraverso il faro e poi non riescono a costruire un percorso diretto, e il primo istinto è attivare ogni opzione punchy. Quell’istinto produce una configurazione con tre modifiche e nessuna idea di quale contasse. Le impostazioni rispondono a domande diverse: una mantiene una mappatura che esiste già, e un’altra tenta una stretta di mano nella direzione opposta. Decidete quale domanda avete prima di toccare l’una o l’altra.

Verificate l’estremità prima del tempo

Un peer che non appare mai all’indirizzo atteso non sarà salvato dalla messa a punto di punch. Controllate cosa sa il faro del peer e cosa annuncia la sua stessa configurazione, perché un indirizzo bootstrap obsoleto o un indirizzo privato pubblicato per errore vanifica ogni trucco di attraversamento. Confermate anche che il certificato sia fidato, dato che un’identità non fidata ferma la conversazione molto prima che il NAT conti. Poi verificate che l’UDP raggiunga almeno il faro. I valori di tempo sono l’ultima cosa da guardare, non la prima.

Annotate la coppia di estremità con cui provate, così che i confronti successivi usino gli stessi peer e non altre due macchine.

punch conserva una mappatura, respond apre una direzione

L’opzione punch invia periodicamente pacchetti vuoti all’indirizzo di sottolivello di un peer che ha già un tunnel. Il suo scopo non è glorioso: impedisce a un NAT con stato o a un firewall di far scadere la mappatura da cui dipende il percorso diretto. L’opzione respond cambia ciò che accade a una notifica del faro, facendo tentare all’host una stretta di mano verso il peer che cerca di raggiungerlo. Sono meccanismi diversi con modi di guastarsi diversi.

Scegliete punch quando il percorso diretto funziona e poi decade. Scegliete respond quando il percorso non si forma mai in una direzione. Attivare entrambi e sperare è il modo in cui una correzione di cinque minuti diventa una settimana di messa a punto.

I ritardi decidono quando, non se

I valori di ritardo spostano il momento: uno vale per il pacchetto inviato dopo una notifica, l’altro per il tentativo di stretta di mano inversa. Nessuno dei due rende funzionante una direzione bloccata. Cambiare entrambi insieme distrugge il confronto che stavate per fare.

Lasciateli stare finché il meccanismo non è corretto. Poi regolatene uno, e annotate il vecchio valore.

Quando un relè è la risposta onesta

Alcune combinazioni di NAT non possono sostenere un percorso diretto, comunque si disponga il tempo. Un NAT simmetrico su entrambi i lati, o un firewall che scarta del tutto il traffico in ingresso non richiesto, non lasciano nulla da perforare.

Un nodo relè con un indirizzo raggiungibile dà a quei peer un percorso che non dipende dal successo dell’attraversamento. Costa larghezza di banda attraverso quel nodo, quindi è una decisione sulla capacità e non una scorciatoia. Configurate il relè di proposito e verificate che i peer possano raggiungerlo, perché un relè che sta esso stesso dietro un NAT difficile non cambia nulla. Poi smettete di regolare le impostazioni punch per quella coppia, dato che il percorso diretto non sarebbe mai apparso.

Provate la coppia che ha fallito, dopo l’inattività

Riproducete la condizione che si è rotta: lasciate la coppia inattiva per lo stesso intervallo, o ripetete la sequenza di strette di mano che prima falliva. Poi esercitate l’applicazione tra quei due peer, non una richiesta al faro. Una risposta del faro dimostra il percorso di controllo e nulla sul percorso dati.

Annotate quale impostazione è cambiata, l’ora, e se è apparso un percorso diretto o il traffico è rimasto sul relè. Se è rimasto, la risposta è un relè e una nota di capacità, ed è un risultato del tutto buono. Se è apparso, la domanda successiva è se sopravvive un’ora di inattività, perché una mappatura che decade è esattamente il problema per cui punch esiste.