Il tuo client OpenVPN deve usare nobind o una porta fissa?

Due profili che differiscono di una sola riga si comportano in modo diverso nel momento in cui un secondo client parte sullo stesso host. Uno porta nobind e prende qualunque porta locale gli assegni il kernel; l'altro riserva 1194, e la seconda istanza muore con un indirizzo già in uso. Quella riga decide chi sceglie la porta di origine, il che a sua volta decide se il profilo può convivere con qualsiasi altra cosa sulla macchina. Tre domande lo risolvono, e la prima risponde alla maggior parte dei profili prima di arrivare alle altre due.

Cosa salta davvero nobind

Per impostazione predefinita il client collega un socket locale prima di chiamare, e la porta locale è 1194 salvo diverse indicazioni del profilo. nobind rimuove quella prenotazione, quindi lo stack assegna una porta inutilizzata al momento della connessione. È un'eccezione, non un valore predefinito, e un client senza la riga mantiene 1194, ed è esattamente per questo che una seconda istanza non fissata va in conflitto. La maggior parte dei profili client distribuiti porta la direttiva proprio per questo motivo, e il fatto che un file di esempio faccia qualcosa non equivale a un meccanismo che lo fa per impostazione predefinita.

Ciò che non cambia è il lato remoto. Il server continua ad ascoltare dove il profilo dice che ascolta, e la porta di destinazione nella configurazione è ancora la porta di destinazione. Una porta di origine dinamica cambia l'indirizzo di ritorno del tuo socket e nulla di quello del server.

Non nasconde nulla, inoltre. Il tuo indirizzo pubblico è ciò in cui il percorso lo traduce, il pacchetto attraversa ancora la rete locale, e chi gestisce quella rete vede ancora un flusso. nobind non è né una funzione di privacy né un aggiramento del firewall.

Tre condizioni che lo decidono

Una domanda decide le altre due, quindi rispondi prima di modificare qualsiasi cosa. Se il peer chiama verso l'esterno, le domande restanti affinano solo una decisione già presa. Se accetta connessioni in entrata, nessuna regolazione della porta locale lo rende raggiungibile.

Questo peer avvia la connessione? Se chiama verso l'esterno, una porta di origine dinamica è innocua e di solito preferibile, perché la risposta torna dallo stesso flusso. Se attende connessioni in entrata, una porta dinamica lo rende irraggiungibile a meno che qualcosa davanti non pubblichi la porta. Quella singola risposta separa ogni profilo client da ogni profilo server.

Il percorso filtra sulla porta di origine? Una regola rigida scritta per una porta nota impone una porta locale esplicita, e il profilo dovrebbe annotare quale regola soddisfa. La maggior parte delle reti filtra solo sulla destinazione, quindi questa condizione è più rara della prima. Dove si applica, ha la meglio sulla preferenza per una porta dinamica.

Più istanze condividono l'host? Una singola porta fissa non può servirne due, e un'istanza riavviata può trovare 1194 ancora in stato di chiusura. Le porte dinamiche eliminano quel conflitto senza cambiare nient'altro. Se non puoi rispondere con sicurezza, supponi di sì e lascia scegliere il kernel.

Dove una porta fissata è la risposta giusta

Alcune reti filtrano sulla porta di origine oltre che sulla destinazione, quindi un operatore potrebbe aver scritto una regola che lascia passare solo il traffico da una porta nota. Fissare la porta locale è allora corretto, e il profilo dovrebbe portare un commento che nomina la regola soddisfatta. Fissare per simmetria con la porta del server non è un motivo, perché i due numeri non hanno nulla a che vedere l'uno con l'altro. Se il fissaggio esiste solo perché un modello lo aveva, cancellalo.

Altrimenti una porta fissata compra guai: due client su una macchina non possono entrambi tenere 1194, e il secondo fallisce con un errore che punta alla porta invece che al profilo. Un container che si riavvia rapidamente sbatte contro lo stesso muro. La riparazione è la direttiva che i profili distribuiti già contenevano.

Server e client non sono simmetrici

manuale di OpenVPN 2.6 colloca nobind accanto a lport, che è l'argomento in una riga: un'opzione dice che sceglie il kernel, l'altra dice che scegli tu. Una porta locale dinamica funziona solo per il peer che chiama, perché il lato che risponde non può conoscere la porta in anticipo. Per questo copiare un profilo client su un server produce un ascoltatore che nessuno può raggiungere.

Su un host con più interfacce di rete l'indirizzo è una decisione separata dalla porta. Collegare un indirizzo locale specifico e collegare una porta specifica sono due impostazioni diverse, e un server con due collegamenti in salita di solito fissa entrambi. Un client che fissa entrambi ha assunto la stessa rigidità senza alcun beneficio.

Il riepilogo riguarda i ruoli, non la sicurezza: chi chiama può essere flessibile sul proprio origine, e chi risponde non può. Nessuna delle due scelte cambia ciò che l'altro estremo impara sulla tua identità. Per questo la direttiva compare negli esempi client e quasi mai in quelli server.

Verifica la porta scelta dal kernel

Dopo la connessione leggi il socket invece della configurazione, perché la configurazione dichiara l'intenzione e il socket dichiara cosa è successo. I fatti che vale la pena registrare sono la porta locale, l'endpoint remoto e se qualcosa sta ancora ascoltando. Su un host Linux tutti e tre sono a un comando di distanza.

ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn

Un client con nobind mostra una porta locale alta e la porta remota configurata, che è la forma attesa. Un server mostra un socket in ascolto sulla sua porta configurata, e se quel socket manca il profilo o non è un ascoltatore o non è riuscito a collegarsi. Quando esiste un flusso ma non tornano pacchetti, confronta la porta di origine scelta con qualsiasi filtro di porte sul percorso prima di modificare il profilo. Cambia una cosa, riconnettiti e rileggi il socket.