Quale componente possiede davvero un limite di rotte di OpenVPN?

Un profilo che porta duecento rotte funziona su una macchina e ne installa quaranta su un’altra. Il motore, l’integrazione che lo avvia e il server che lo alimenta hanno voce in capitolo, e ciascuno può fermare l’elenco in un punto diverso. Leggere il guasto come un unico limite vi manda al file sbagliato. Il meccanismo ha tre fasi, e la fase che si è fermata lascia prove visibili quando sapete cosa cercare.

Tre fasi, tre limiti diversi

Prima il motore analizza l’opzione e decide se questa versione la comprende. Poi l’integrazione installa ciò che il motore riporta, e il suo codice può tappare o rimodellare l’elenco. Infine il server decide quante rotte invierà a una data identità, prima che una qualsiasi fase lato client veda qualcosa. Tre fasi, tre tetti, e solo uno di essi è il numero nel profilo.

Alzare un tetto non fa nulla per gli altri. Una rotta inviata e rifiutata può essere una decisione di politica sul server, una sovrapposizione risolta dal client, o un limite dell’installatore che ha scartato l’eccesso. Ognuno di questi casi ha una correzione diversa.

Separate i tre prima di misurare qualsiasi cosa. Un errore dell’analizzatore nomina un token, un limite dell’installatore lascia una tabella di rotte corta, e una decisione di politica non lascia proprio nulla. Le prove vi dicono quale fase ispezionare per prima.

L’analizzatore parla per primo

Un’opzione sconosciuta fallisce rumorosamente e presto, e il testo dell’errore nomina il token. È la fase più facile da identificare: confrontate il messaggio esatto con la versione installata del motore, perché un’opzione aggiunta in una versione è sconosciuta in quella precedente. Un profilo copiato da un’installazione più recente è la causa abituale di questa discordanza. L’analizzatore non ignora mai in silenzio una direttiva che non riconosce.

Un’opzione accettata non dice nulla sul risultato. L’analisi riesce, e l’elenco può comunque essere tagliato dall’installatore o non essere mai offerto dal server. Trattate un’analisi pulita come permesso di proseguire, non come prova.

Annotate la stringa di versione dal binario che è stato davvero eseguito, non dall’idea che il gestore di pacchetti ha di ciò che è installato. Quei due sono in disaccordo più spesso di quanto ci si aspetti.

L’installatore ha il suo tetto

Il componente che possiede l’attivazione può essere un plugin di NetworkManager invece del binario del motore, e può imporre il proprio limite prima che esista un solo tunnel. Il suo editor può mostrare un campo che il motore in esecuzione non legge mai, o leggere un campo che l’editor non mostra. Entrambe le situazioni sembrano un difetto del client dall’esterno. Nessuna delle due si corregge modificando il profilo.

Contate ciò che è arrivato invece di ciò che è stato configurato. Il comando ip route show dev tun0 elenca le rotte installate, e confrontare quel conteggio con l’elenco inviato separa una rotta scartata da una che non è mai stata inviata. Un conteggio che corrisponde all’invio riporta il sospetto al server.

Un involucro di shell attorno al binario del motore per forzare un numero più grande offusca gli aggiornamenti e trasforma il ritorno indietro in un indovinello. Nasconde anche il limite reale a chiunque leggerà la configurazione in seguito.

Il server decide cosa vi è stato offerto

La politica per client può ridurre l’elenco prima della trasmissione. Un file specifico del client può aggiungere rotte per un’identità, o una politica di gruppo può ometterle, e il client non può distinguere una rotta filtrata da una mai definita. È questa ambiguità che rende importante il registro del server. Chiedete l’elenco di invio effettivo per quell’identità, non il modello.

Confrontate il registro del server con l’elenco ricevuto. Lo scarto tra i due è lo strato di politica, ed è di solito più piccolo di quanto il profilo suggerisca.

Quando il progetto lo consente, riassumete le reti contigue ed eliminate le voci obsolete. Meno rotte e più ampie risolvono più casi di un tetto più alto.

Cambiate il numero nel posto giusto

Usate l’impostazione documentata del componente che possiede davvero il limite. Se il campo manca nel plugin, verificate se il plugin è anteriore alla funzione o se un altro motore di fondo possiede le rotte. Poi documentate le versioni del motore, del plugin e del server accanto al valore scelto. Il prossimo aggiornamento riapre la questione, e la nota è ciò che la rende risolvibile.

Provate di nuovo dopo qualsiasi aggiornamento di uno dei tre. Un limite alzato nel posto giusto si sposta comunque quando cambia il componente che lo applica. Il registro delle versioni è l’unica cosa che rende prevedibile quello spostamento.