Router VPN: LAN e WAN, cosa annotare prima di acquistare
Un’etichetta VPN non dice nulla su VLAN, failover WAN o ruoli dei tunnel. Annotate le capacità esatte del modello e del firmware che intendete distribuire.
Trattate l’etichetta pronta per VPN come una funzione tra le altre di un dispositivo che deve anche instradare, segmentare e commutare in caso di guasto, perché l’etichetta non dice nulla su quante reti separate l’apparecchio può ospitare. Iniziate scrivendo un registro delle capacità per il modello e il firmware esatti, poi confrontate quel registro con i flussi di cui ha bisogno il sito. Le pagine di marketing elencano le prese; raramente elencano l’appartenenza a una VLAN, la politica di failover o l’ambito del tunnel. Il registro richiede una ventina di minuti e risolve la maggior parte delle discussioni d’acquisto prima che arrivi l’hardware.
Fissate l’apparecchio esatto prima di tutto il resto
I nomi dei modelli viaggiano tra generazioni di firmware, e lo stesso involucro può essere fornito con un driver dello switch diverso a seconda della versione. Leggete l’identità della scheda dall’apparecchio stesso invece che dal cartone, così ogni affermazione successiva resta legata a qualcosa che potete riprodurre. Un solo comando copre modello, nome della scheda e versione del firmware su OpenWrt, e le schermate equivalenti esistono nella maggior parte dei firmware aziendali.
ssh [email protected] 'ubus call system board'
cat /etc/openwrt_releaseScrivete quelle stringhe nel registro, mai abbreviate. Poi separate il normale lavoro di routing da quello del tunnel. Un dispositivo che inoltra bene i pacchetti può comunque rifiutarsi di terminare un tunnel, e un dispositivo che termina un tunnel può non avere modo di tenere separate due reti locali. Trattare i due come un unico requisito nasconde la discrepanza finché l’unità non è già montata nel rack, configurata e a metà considerata affidabile.
Annotate la struttura della LAN, non il numero di porte
Quattro prese di solito significano un solo switch, e uno switch significa un solo dominio di broadcast, a meno che non siano configurate VLAN. Va bene per una rete domestica piatta ed è sbagliato per un sito che vuole un segmento ospiti, un segmento di gestione e un segmento telecamere isolato sullo stesso apparecchio. Annotate quali porte appartengono a quale VLAN, quali VLAN raggiungono la CPU e quali interfacce portano indirizzi.
Dove il firmware offre VLAN, l’elenco delle interfacce decide quante politiche distinte potete scrivere. Una VLAN definita sullo switch ma mai assegnata come interfaccia non ha indirizzo né zona firewall, quindi non può imporre nulla da sola.
| Field to record | Example entry | Review stops if |
|---|---|---|
| Ports and VLAN membership | ports 1-4 untagged on VLAN 10, port 5 trunk with VLAN 10 and 20 | the datasheet offers only a socket count |
| Routed interfaces | br-lan 192.168.88.1/24, vlan20 192.168.99.1/24 | two subnets cannot hold separate policies |
| WAN method and failover | DHCP on wan, PPPoE on wan2, policy route to wan2 on loss | only one uplink is configurable |
| Tunnel role and scope | WireGuard peer on the router, only 192.168.88.0/24 routed inside | the router can only pass another tunnel through |
Leggete lo stato dello switch invece di fidarvi del menu. Sui vecchi target OpenWrt lo strumento dello switch stampa i dispositivi configurati, e sui target DSA gli strumenti del bridge riportano gli stessi fatti per porta, per questo la versione del firmware appartiene al registro.
Annotate il comportamento di WAN e failover
Metodo di accesso, proprietà dell’indirizzo e ordine di failover stanno su una riga per collegamento in uscita, perché un tunnel che sopravvive a un cambio di WAN dipende da tutti e tre. Una sessione PPPoE si riconnette con un nuovo indirizzo e fa cadere il tunnel con sé, mentre un collegamento DHCP che conserva il suo lease può non farlo.
Il failover richiede anche una decisione di politica. Mandare tutto il traffico sul collegamento di riserva è facile; tenere il tunnel sul primario mentre il traffico web ordinario usa la riserva richiede routing basato su policy, e non tutti i firmware lo espongono. Annotate se il tunnel è legato a un solo collegamento in uscita e cosa fa il dispositivo alle sessioni stabilite quando quel collegamento sparisce. Conservate la tabella di routing come prova, non la casella del failover.
Provate un flusso consentito e uno negato
Il registro vale la pena di essere conservato solo se il dispositivo può essere accettato in base a esso. Scegliete un flusso che deve funzionare, uno che non deve, ed eseguite entrambi da un client sul segmento in questione. Un tunnel che trasporta tutte le sottoreti è un fallimento quando il requisito era una sola sottorete.
Poi confermate il rifiuto, perché un valore predefinito permissivo è la solita sorpresa. Il segmento ospiti non deve raggiungere l’indirizzo di gestione, e il controllo dovrebbe mostrare un timeout o un rifiuto invece di una pagina di accesso.
curl -sS --max-time 8 https://api.ipify.org
ping -c 2 192.168.99.1
ip -4 route get 192.168.99.1Se il flusso consentito funziona e anche quello negato funziona, manca la segmentazione anche se i menu suggerivano il contrario. Se falliscono entrambi, l’ambito del tunnel o il percorso di ritorno sono sbagliati, e il registro WAN di solito spiega quale. Conservate i due risultati con il registro delle capacità, così il prossimo revisore vede cosa è stato accettato, su quale firmware e in quale data.