Nuovo router, stesso server VPN: spostate il suo ingresso pubblico

Collegate il router nuovo, internet torna, e il client VPN sul telefono punta ancora a un indirizzo che non risponde più. Sul server VPN non è cambiato nulla, perché il server non si è mai spostato. Il router era il punto di ingresso pubblico, e sostituirlo ha sostituito l’indirizzo, la regola di inoltro e forse l’aggiornatore del DNS dinamico nello stesso momento.

Trattate la sostituzione come due passaggi di consegne, non uno, e tenete un accesso locale all’interfaccia di amministrazione mentre lavorate.

Scrivete il passaggio di consegne prima di scollegare

Annotate il prefisso LAN, l’indirizzo del server e come viene assegnato, l’ascoltatore e il trasporto che il VPN usa davvero, la regola in ingresso che lo pubblica e il nome che i client hanno salvato. Poi annotate quale macchina aggiorna oggi il record DNS dinamico: può essere il router, il server stesso o un agente separato su un altro host. Fatelo mentre le vecchie pagine di amministrazione si caricano ancora. Uno screenshot della regola in ingresso vale più di un numero di porta ricordato.

Aggiungete i prefissi privati che i client devono raggiungere, e come i dispositivi sulla LAN inviano loro le risposte. Entrambe le cose si dimenticano facilmente perché la procedura guidata di sostituzione parla di accesso a internet, non di percorsi di ritorno. Esportate anche la vecchia configurazione se il produttore ne supporta il ripristino, accettando che un backup di un modello raramente si importa pulito in un altro.

Conservate quel registro in un luogo protetto. Un backup del router può contenere credenziali per il collegamento WAN. Trattate il file esportato come una password e non come una nota sulle impostazioni.

Spostate prima l’indirizzo, poi l’inoltro

Se il router nuovo mantiene lo stesso prefisso LAN, date al server la prenotazione che aveva, o un’assegnazione statica equivalente. Se il prefisso cambia, aggiornate prima l’indirizzo del server e ogni associazione dell’ascoltatore che lo nomina, perché un inoltro verso il vecchio indirizzo manderà il traffico silenziosamente nel nulla.

Poi ricreate esattamente una regola in ingresso per il trasporto che il VPN usa. Le guide dei produttori che descrivono l’inoltro verso un server locale mostrano il meccanismo, non una ricetta universale, quindi adattate la regola al vostro protocollo e alla vostra porta reali e non a un elenco trovato su un blog. Un inoltro sul router nuovo non può rimuovere il NAT di livello operatore che sta sopra, e nessuna regola locale renderà un indirizzo privato raggiungibile da internet se il fornitore ne condivide già uno con voi.

Verificate che il firewall del server stesso consenta ancora quel traffico. Controllate se tra il router e internet c’è un secondo gateway, perché molti fornitori consegnano modem e router combinati. Leggete l’indirizzo WAN sul nuovo dispositivo e confrontatelo con l’indirizzo che i client risolvono. Se differiscono, il vostro inoltro sta atterrando su qualcosa che non è il bordo.

Decidete chi aggiorna il nome pubblico

Gli aggiornamenti dell’endpoint richiedono un proprietario e uno solo. Se il vecchio router pubblicava il nome, configurate un aggiornatore supportato sul sostituto e confermate che il record è davvero cambiato. Se il server lo pubblicava già, lasciate in pace quella disposizione invece di aggiungere un aggiornatore concorrente che oscilla tra due indirizzi.

Quando la distribuzione pubblica entrambe le famiglie di indirizzi, leggete sia il record A sia il record AAAA. Ognuno deve puntare a un servizio che ascolta davvero e che è consentito dal proprio percorso del firewall, e una mappatura IPv4 funzionante non dice nulla sul lato IPv6. Mantenete anche i controlli di identità nel profilo del client: un indirizzo pubblico cambiato non è un motivo per accettare un certificato o una chiave di pari che non corrisponde.

Dimostrate la sostituzione dall’esterno

Provate con una connessione esterna autorizzata e una sessione nuova, non dall’interno della LAN. Un test interno verso l’indirizzo pubblico dipende dal comportamento di ritorno verso il proprio indirizzo e percorre un cammino diverso da quello di un client reale.

Seguite la sequenza che segue un client: risolvete il nome, negoziate il tunnel, autenticatevi, poi eseguite un’operazione verso una risorsa privata. È proprio quest’ultimo passo che la gente salta, ed è l’unico che dimostra il percorso di ritorno. Se l’accesso riesce ma l’operazione privata fallisce, confrontate il nuovo prefisso LAN, le rotte scelte dal client e il percorso di risposta della risorsa con le vostre note di passaggio di consegne.

Solo quando i quattro passi sono tutti superati il vecchio router può essere ritirato in sicurezza. Scollegatelo, poi ripetete ancora una volta il test esterno. Un record obsoleto che risolve ancora al vecchio indirizzo fallisce già al primo passo, ed è più facile diagnosticarlo mentre il vecchio dispositivo è ancora sullo scaffale.

Tenete la nuova mappatura con le vostre note di ripristino

Archiviate l’assegnazione finale del server, la regola in ingresso e il nome del proprietario dell’aggiornamento accanto alla procedura per raggiungere il router localmente. La prossima sostituzione dovrebbe partire da quella pagina e non da un traceroute.

Se il tunnel fallisce ancora dall’esterno dopo tutto quanto sopra, controllate se l’indirizzo pubblico riportato dal router coincide con quello che i client risolvono. Quell’unico confronto separa un problema di DNS da un problema di inoltro, e richiede meno tempo che leggere un’altra guida sull’inoltro delle porte.