ifconfig-push: indirizzo del peer in net30 o netmask in subnet?

I client dinamici si connettono e l’instradamento funziona bene, ma l’unico client con un indirizzo fisso non raggiunge affatto il server. Nulla nel firewall è cambiato, e la riga CCD sembra plausibile. La causa abituale è un secondo argomento scritto per una topologia TUN diversa da quella che il server esegue. Il guasto è silenzioso: il client sale con un indirizzo e il server accetta la connessione, ma non passa alcun traffico.

In net30 quel campo è un indirizzo del peer; in subnet è una netmask. Le due forme sono alternative, mai una sequenza.

Le due forme, affiancate

In una distribuzione net30 tradizionale ogni client possiede un blocco /30: un indirizzo di rete, due indirizzi utilizzabili e un indirizzo di broadcast. ifconfig-push prende l’indirizzo del client e l’indirizzo del peer, e il peer è l’altro indirizzo utilizzabile nello stesso blocco, usato dal lato server del collegamento punto a punto.

# net30: client address and its peer
ifconfig-push 10.99.0.6 10.99.0.5
# topology subnet: client address and the pool netmask
ifconfig-push 10.99.0.20 255.255.255.0

Sotto topology subnet il client condivide una subnet con il server, e la stessa direttiva prende un indirizzo e una netmask. L’indirizzo del server stesso proviene dalla direttiva server, non dal secondo campo. Mescolare le forme produce un client che crede di trovarsi su un collegamento punto a punto mentre il server lo instrada come host di subnet, o il contrario. Ecco perché una netmask non deve mai essere abbinata a net30.

Entrambe le righe del blocco sono righe singole per un file CCD. Ogni client ne riceve esattamente una.

Leggete la topologia che il server esegue davvero

Leggete la configurazione in esecuzione anziché un valore predefinito del pacchetto, perché la topologia potrebbe essere stata impostata anni fa e copiata in avanti. Cercate topology subnet o la sua assenza, poi controllate come la riga server assegna gli indirizzi. Una configurazione che non menziona mai la topologia non è la stessa di una che imposta subnet.

Poi leggete le impostazioni ricevute dal client. L’indirizzo, la netmask e il peer che riporta vi dicono quale interpretazione ha applicato il server.

Tenete l’indirizzo fisso fuori dal pool dinamico

Un indirizzo fisso deve stare fuori dal pool dinamico, altrimenti due client possono ricevere lo stesso indirizzo. Con la topologia subnet, nopool sulla riga server sopprime il pool automatico, e un intervallo ifconfig-pool esplicito definisce ciò che i client dinamici ricevono.

dev tun
topology subnet
server 10.99.0.0 255.255.255.0 nopool
ifconfig-pool 10.99.0.100 10.99.0.210 255.255.255.0
client-config-dir /etc/openvpn/ccd

Il server prende 10.99.0.1 per sé, e l’indirizzo fisso del client resta fuori dall’intervallo del pool. Il file CCD è nominato dall’identità effettiva del client, non dal nome del file di profilo, e non riceve alcuna estensione aggiuntiva. Se username-as-common-name è attivo, il nome utente autenticato è l’identità da confrontare. Due dispositivi che condividono una identità condivideranno anche l’indirizzo fisso, il che è un problema di criterio e non di instradamento.

Verificate l’assegnazione che il client ha realmente ricevuto

Riconnettete il client previsto e confermate quale file CCD è stato selezionato prima di controllare qualsiasi altra cosa. Poi verificate l’indirizzo, la netmask o il peer, e la rotta di ritorno al server. Un client che mostra un indirizzo del peer in una distribuzione subnet usa ancora la forma sbagliata.

Cambiare la topologia influisce su ogni client e ogni sostituzione, quindi trattatelo come una migrazione e non come una riparazione di un solo client. Correggere la riga statica per corrispondere alla topologia già in uso è di solito la modifica più piccola. riferimento server-options documenta l’helper e le sostituzioni specifiche del client.