IP statico OpenVPN per client: ifconfig-push, non ipp.txt

Modificare una riga in ipp.txt sembra prenotare un indirizzo, e non lo è. Quel file, nominato da ifconfig-pool-persist, registra quale indirizzo aveva un nome comune l'ultima volta, così il pool può restituire lo stesso quando conviene. Nulla in esso lega la connessione successiva a quel numero.

Esegui i controlli seguenti in ordine. Ognuno conferma il meccanismo oppure ti dice di fermarti e riparare un input.

A cosa serve il file di persistenza

Il file esiste per mantenere stabili gli indirizzi tra i riavvii, il che rende le riconnessioni più amichevoli e i log più facili da leggere. Viene letto come storia e scritto come storia, e il percorso di allocazione resta libero di scegliere un altro indirizzo quando il suggerimento non si adatta: un altro pool, un'assegnazione in conflitto o un client arrivato dopo che il pool si è riempito. Per questo una modifica manuale può sembrare perfetta nel file e non cambiare nulla della connessione. Trattalo come una cache delle decisioni passate, non come una fonte di politica.

Se ti serve un indirizzo specifico per un client specifico, il meccanismo documentato è ifconfig-push, e appartiene alla configurazione che possiede quel client.

Verifica che sia selezionato il client giusto

Un'assegnazione esplicita viene cercata per nome comune del client, quindi un file nominato per l'identità sbagliata semplicemente non viene mai letto. Conferma cosa il server considera il nome di quel client, soprattutto dove username-as-common-name lo cambia dopo l'autenticazione. Poi conferma che il nome del file corrisponda esattamente a quel valore, comprese le maiuscole e minuscole.

Considera la concorrenza mentre sei qui. Se duplicate-cn è consentito, più dispositivi possono presentare la stessa identità, e un indirizzo fisso non può essere univoco per tutti. Decidi se l'indirizzo fisso vale il rifiuto delle sessioni simultanee per quell'identità, perché questi due requisiti non possono essere soddisfatti insieme.

Verifica che i numeri corrispondano alla topologia

Il significato degli argomenti dipende dalla topologia del tunnel, ed è qui che un esempio copiato fa più danni. Nella vecchia disposizione net30 ogni client occupa un blocco di quattro indirizzi, quindi il push fornisce una coppia di indirizzi. Nella topologia di sottorete il client riceve un indirizzo più la maschera del pool, e la forma a coppia è sbagliata. Leggi la topologia dalla configurazione in esecuzione prima di scrivere la riga.

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

Verifica l'indirizzo contro tutto il resto che potrebbe possederlo: un'altra assegnazione esplicita, l'intervallo del pool dinamico e qualsiasi rotta statica che presupponga un host fisso. Un indirizzo che si sovrappone al pool funzionerà finché il pool non lo darà a qualcun altro, e quel guasto sembrerà casuale.

Verifica il risultato su una nuova connessione

Una sessione esistente conserva l'indirizzo che le è stato dato, quindi l'unico test significativo è una nuova connessione. Disconnetti il client, riconnettilo e leggi l'indirizzo che ha effettivamente ricevuto insieme alle rotte che sono arrivate con esso. Se l'indirizzo è ancora dinamico, l'assegnazione non è stata applicata, e il passo successivo è la ricerca nella configurazione e non un'altra modifica del file di storia.

Tieni insieme le prove: il nome del client, il file che ha corrisposto, l'indirizzo assegnato e il pool da cui è arrivato.

Infine, un indirizzo di tunnel fisso non è una credenziale del dispositivo. Identifica un punto nel piano degli indirizzi, mentre l'autenticazione poggia ancora sul certificato e sull'account. Confondere i due trasforma un conflitto di indirizzi in un'assunzione di sicurezza che nessuno ha scritto.