Aggiungi una VPN di sito accanto al router dell’ISP senza interrompere le chiamate

La maggior parte dei piccoli siti ha già una scatola che fa internet, DHCP e la linea voce, e quella scatola non porterà il tunnel del sito. Aggiungere un secondo gateway per il percorso privato funziona, purché si decida chi possiede ogni rotta prima di toccare un cavo. Il rischio vero non è il tunnel; è cambiare in silenzio il dispositivo che tiene registrati i telefoni. Esegui i cinque controlli in ordine e fermati dove uno fallisce.

Annota i ruoli che già funzionano

Registra il gateway predefinito, il server DHCP, il resolver e il dispositivo che detiene la registrazione voce del provider. In questo esempio il router dell’ISP è 10.50.0.1, il nuovo gateway sarà 10.50.0.2 e il sito remoto è 10.60.0.0/24. Nulla in quel piano cambia i primi tre ruoli, ed è esattamente il punto. Poi verifica che la seconda scatola possa davvero terminare il tunnel: controlla il protocollo, il throughput atteso e se riceve aggiornamenti firmware o dei pacchetti. Un dispositivo con il logo VPN e senza percorso di aggiornamento è un peso, non un’aggiunta.

Se non puoi dire chi possiede il servizio voce, fermati. Cambiare il router che detiene una registrazione senza un piano di ritorno trasforma un progetto VPN in un’interruzione telefonica.

Dai al nuovo gateway un indirizzo e un compito

Riserva il suo indirizzo LAN fuori dal pool DHCP perché non si sposti dopo un riavvio, e non dargli una rotta predefinita propria se non vuoi che diventi un percorso internet. Il suo compito è tenere il tunnel e rispondere per i prefissi remoti. Sugli host della LAN che devono raggiungere il sito remoto, dimostra quale rotta usano ora e quale vuoi dopo il cambiamento; gli stessi due comandi prima e dopo sono la prova più economica.

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

Se la ricerca restituisce il router dell’ISP e il traceroute muore al bordo di internet, l’host non ha ancora una rotta remota, cosa attesa. Se restituisce qualcosa di inatteso, risolvilo prima, perché ogni passo successivo dà per scontata questa base.

Scegli chi possiede la rotta del prefisso remoto

L’opzione A è il router dell’ISP: tiene una rotta statica per 10.60.0.0/24 verso il gateway e ogni host segue il suo gateway predefinito come prima. L’opzione B è per host: solo le macchine che hanno bisogno del sito remoto ricevono una rotta esplicita via 10.50.0.2, e tutto il resto resta intatto. A è più pulita con molti host, ma di solito richiede che il router del provider accetti una rotta statica, cosa che alcuni non fanno. B non richiede collaborazione del provider ma lascia a te la manutenzione della configurazione degli host, quindi si addice a un piccolo insieme di macchine approvate.

In entrambi i casi la direzione di ritorno deve esistere. Se una risposta remota arriva al gateway e il gateway la inoltra direttamente a un host della LAN, il traffico salta lo stato del firewall che il router dell’ISP teneva sul percorso di andata. Quando il gateway non è il router predefinito della LAN, quell’asimmetria è una decisione di progetto, non un difetto da ignorare.

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

Rendi permanente la voce tramite il proprietario della configurazione dell’host, non tramite uno script di accesso. Una rotta che esiste solo dopo un accesso fallirà la prima volta che la macchina si riavvia per un motivo non correlato.

Prepara un punto di ingresso raggiungibile

Il gateway ha bisogno di un indirizzo che il sito remoto possa raggiungere. Dietro il router dell’ISP significa un port forwarding o una voce DMZ, ed entrambi dipendono dal fatto che il provider consegni davvero il traffico. Un inoltro locale non supera il NAT di livello operatore dal lato del provider. Se il provider non dà un punto raggiungibile, inverti la direzione: lascia che entrambi i siti inizino verso un concentratore che controlli. È un progetto valido, ma aggiunge una terza dipendenza per inoltro, fiducia e disponibilità, e il DNS dinamico non la sostituisce.

Conferma l’inoltro con una cattura sul gateway, non con un sito che scansiona le porte. Gli scanner dichiarano la porta chiusa finché l’ascoltatore non è associato, e un inoltro che non consegna mai traffico dall’esterno appare come una porta chiusa.

Accetta il servizio privato e la linea voce insieme

Prova il funzionamento previsto da un host della LAN, con DNS privato e le credenziali dell’applicazione stessa. Un tunnel instradato non fa sembrare la navigazione remota un segmento Ethernet locale, quindi scoperta e risoluzione dei nomi richiedono accordi propri.

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

Poi conferma che l’accesso internet ordinario funzioni ancora dallo stesso host e che i telefoni siano ancora registrati; questi due controlli intercettano un cambiamento accidentale della rotta predefinita, il modo più comune in cui questo progetto rompe qualcosa che non voleva toccare. Chiudi con una nota di ripristino scritta: quale dispositivo ha quale ruolo, gli indirizzi riservati e come rimuovere la rotta del prefisso remoto in un solo passo. Un percorso privato che si può ritirare in modo pulito vale più di uno che funziona solo oggi.