Pensa che rinominare il server Pritunl cambi il suo endpoint?

Rinominare un server Pritunl cambia un’etichetta nella console. Non cambia l’indirizzo a cui si collegano i profili dei client e non crea un record DNS. Il valore che conta è l’Indirizzo pubblico dell’host, e accetta un nome con la stessa facilità di un indirizzo.

Il nome a cui si collegano i client vive in un solo campo dell’host

Pritunl espone l’endpoint tramite l’impostazione Indirizzo pubblico dell’host, che accetta un indirizzo IP pubblico o un nome DNS. Mettete vpn.example.net lì e i profili generati e la sincronizzazione autenticata consegneranno quel nome ai client. Il record deve già esistere e risolversi verso il listener che accetta il trasporto VPN; il campo annuncia una destinazione, non la pubblica. Il nome visualizzato di un oggetto server è metadato amministrativo e non raggiunge mai il tentativo di connessione del client.

Quindi il primo passo non è rinominare qualcosa. Aprite le impostazioni dell’host, cambiate l’Indirizzo pubblico e salvate tramite l’interfaccia supportata.

Tre campi che sembrano uguali e non lo sono

L’Indirizzo locale serve alla replica e al routing tra host Pritunl. L’Indirizzo di collegamento descrive come i server collegati si raggiungono a vicenda. Nessuno dei due è l’indirizzo a cui si collega un client, e copiarvi il nome pubblico rompe la topologia che descrivono. L’Indirizzo IPv6 pubblico è un campo separato con il proprio record e il proprio percorso; un record A per IPv4 non stabilisce la raggiungibilità IPv6.

Un nome DNS non porta neanche una mappatura delle porte né un listener. Se il servizio ascolta su 1194 UDP, il nome si risolve comunque su un host che deve accettare 1194 UDP. Un proxy inverso HTTP sulla porta 443 che serve la console web non è l’endpoint del trasporto VPN, anche quando entrambi condividono lo stesso nome.

Il routing basato sui domini dentro il tunnel è ancora un altro livello. Dare un nome all’endpoint esterno non dice nulla su quali destinazioni private un client possa raggiungere.

Inviate il nuovo nome ai client che esistono

Cambiare il campo non riscrive i profili che hanno già lasciato il server. La sincronizzazione di configurazione autenticata di Pritunl può consegnare le modifiche di indirizzo e porta dell’host ai client compatibili, e il client CLI documentato si sincronizza prima di connettersi o riconnettersi. Un profilo importato in NetworkManager o in un client OpenVPN autonomo non ha un canale del genere e necessita di una sostituzione approvata. Le sessioni esistenti non provano nulla, perché sono state stabilite con il vecchio valore.

Quando la console web si trova dietro un bilanciatore di carico, Pritunl documenta un’impostazione separata Indirizzo di sincronizzazione per il percorso di sincronizzazione. Non riutilizzate il nome host della console per il listener VPN solo perché entrambi sono Pritunl.

Consegnate la modifica in questo ordine: salvate l’impostazione dell’host, esportate o sincronizzate il profilo attuale, sostituite la copia del client e poi riconnettetevi. Annotate quali client sono gestiti dalla sincronizzazione e quali hanno file importati, perché il secondo gruppo non seguirà automaticamente. Un elenco di proprietà dei client è più utile qui che un altro record DNS.

Accettate la modifica con una connessione reale

La risoluzione è il test più debole possibile. dig +short vpn.example.net che restituisce un indirizzo dimostra solo che esiste un record.

Il test di accettazione è una nuova connessione autenticata da un client che possiede il nuovo profilo, seguita da una richiesta a una risorsa privata che dovrebbe essere raggiungibile attraverso il tunnel. Controllate nel log del client l’endpoint che ha effettivamente usato, non quello che intendevate. Mantenete un percorso di gestione che non dipenda dal cambiamento corretto del nome, così un errore non possa bloccarvi fuori dalla console.

Più avanti, quando l’indirizzo pubblico si sposterà, aggiornate il record e pianificate la cache dei client e il comportamento di riconnessione. Un nome host disaccoppia i client da un indirizzo numerico; non sposta un socket attivo né fa rispondere un listener irraggiungibile.