Due indirizzi di servizio su un client OpenVPN: iroute e lo

L’applicazione risponde sul suo indirizzo di tunnel, e l’indirizzo che avete documentato per essa non porta da nessuna parte. Nulla nel registro di OpenVPN si lamenta, il peer appare connesso e l’hub elenca esattamente un client. Il vuoto è che un secondo indirizzo su un client sono due fatti separati: l’host deve possederlo e l’hub deve sapere quale peer lo possiede. Risolvete uno senza l’altro e il traffico o muore all’hub o arriva senza rotta di ritorno.

L’alias è locale, la proprietà è remota

Un indirizzo di tunnel viene negoziato, quindi entrambe le estremità lo apprendono durante l’handshake. Un indirizzo di servizio aggiuntivo non viene affatto negoziato, perciò aggiungerlo non cambia nulla sull’hub da solo. Il client può possedere l’indirizzo subito e il server continuerà a inviare quel traffico sul suo percorso predefinito o lo scarterà. Vanno creati due record, in due posti diversi.

Sul client l’indirizzo appartiene all’host, e loopback è la casa naturale per un’identità di servizio che non dovrebbe mai comparire su un collegamento fisico. Sull’hub la mappatura peer-prefisso è una dichiarazione separata che solo il server legge. Nessuno dei due record implica l’altro.

Tenete separati i due intervalli anche nelle vostre note. Gli indirizzi di un esempio sono valori di documentazione, e sovrapporli a una LAN reale è il modo più rapido per far sembrare rotta una configurazione che funziona.

Aggiungete l’indirizzo sul client in modo persistente

Mettete l’indirizzo di servizio su loopback con un prefisso di host, così l’host lo tratta come input locale e non come una sottorete da raggiungere. ip address add 10.66.0.10/32 dev lo lo fa per un indirizzo, e ripetere il comando per un secondo indirizzo modella due servizi.

Eseguitelo come test una tantum, poi spostatelo in ciò che possiede la configurazione di rete dell’host, perché un’aggiunta a runtime scompare al riavvio e i duplicati si accumulano tra riconnessioni. Un’unità systemd ordinata dopo la rete è un’opzione, e un network manager della distribuzione è un’altra. Qualunque scegliate, l’indirizzo deve esistere prima che l’applicazione si leghi, altrimenti il servizio sale sul socket sbagliato. Verificate con ip address show dev lo dopo un riavvio e non dopo il comando manuale.

Il binding è una decisione separata dall’indirizzamento. Un’applicazione che ascolta su ogni indirizzo accetta traffico su interfacce che non avete mai previsto, quindi puntatela all’indirizzo di servizio specifico. Allora la politica di input locale ha qualcosa di preciso con cui corrispondere.

Reclamatelo nel file CCD che l’hub legge davvero

Sul server, la dichiarazione di proprietà va nel file per client selezionato dal nome comune autenticato, dentro la directory indicata da client-config-dir. La riga è iroute 10.66.0.10 255.255.255.255, una per indirizzo, e dice al server quale peer deve ricevere il traffico per quella destinazione.

Due dettagli rompono tutto in silenzio. Il nome del file deve corrispondere al nome che il server usa davvero, che cambia quando username-as-common-name è in gioco. E iroute ha effetto solo in modalità TUN con una directory di configurazione client configurata, quindi la stessa riga non fa nulla in un deployment in bridge. Aggiungete righe al file esistente invece di sostituirlo, perché potrebbe già portare un indirizzo fisso o opzioni push. La referenza di OpenVPN 2.6 documenta sia la directory sia la direttiva di proprietà.

Anche il kernel dell’hub ha bisogno di un percorso verso quelle destinazioni perché il traffico generato localmente entri nel processo del tunnel. route 10.66.0.10 255.255.255.255 nella configurazione del server copre il traffico che il server origina, mentre gli altri client hanno bisogno di push "route 10.66.0.10 255.255.255.255" per apprendere la destinazione da soli.

Routing e autorizzazione restano separati. Una rotta inviata dice a un client dove mandare i pacchetti e non concede nulla; il servizio deve ancora accettare il chiamante alle proprie condizioni.

Controllate la politica di input e il percorso di risposta

Un pacchetto indirizzato all’alias arriva all’host proprietario come input locale, quindi la domanda è se il firewall locale consente quella sorgente e quella porta. Consentite la porta di servizio specifica dall’intervallo di sorgenti VPN invece di aprire l’intero indirizzo.

Le risposte hanno bisogno di un percorso di ritorno verso il chiamante. Per un chiamante nel pool di tunnel normale quel percorso esiste già, perché lo trasporta il dispositivo di tunnel. Un chiamante dietro un’altra rete instradata ha bisogno anche della rotta di ritorno di quella rete, ed è qui che le configurazioni asimmetriche perdono pacchetti.

Fate attenzione a un secondo listener sulla stessa porta legato a un indirizzo diverso, perché il kernel consegna al socket che corrisponde e i risultati sembrano casuali. Controllate con ss -lntp e confermate che l’indirizzo legato è l’alias del servizio. Il NAT di origine non è necessario qui, e aggiungerlo nasconde l’identità del chiamante da cui dipendono i vostri log.

Testate indirizzi e proprietà separatamente

Testate in due passi. Prima confermate che l’host proprietario può raggiungere il servizio sul suo alias da se stesso, il che separa i problemi di binding e firewall dal routing. Poi testate da un chiamante VPN reale usando l’autenticazione dell’applicazione stessa. Quando il primo passa e il secondo fallisce, il pezzo mancante è sul lato hub.

Controllate anche le modalità di guasto che sopravvivono a una connessione: l’alias resta assegnato quando il tunnel è abbassato, e l’hub conserva la sua rotta quando il peer è assente. Nessun oggetto da solo dimostra che il servizio sia raggiungibile, perciò il test in due passi batte un singolo ping da un portatile.