Regole VPN sul router: abbina l’origine e la destinazione
Una regola VPN sul router ha due estremità: il dispositivo che invia il traffico e la destinazione che deve usare il tunnel. Decidi prima l’intersezione e il comportamento di riserva.
Le pagine d’acquisto dei router presentano l’instradamento VPN come una casella, e la frase nasconde tre domande diverse. La regola corrisponde al dispositivo che invia il traffico, al server che lo riceve o a entrambi? Che cosa succede al traffico che non corrisponde a nessuno dei due? E quando due regole si sovrappongono, quale vince? Scrivere la risposta come coppia di origine e destinazione trasforma un vago elenco di funzioni in un progetto verificabile.
Il nome della funzione nasconde due estremità
Un lettore multimediale che deve usare il tunnel è una corrispondenza di origine. Un prefisso di ufficio privato che deve essere raggiungibile dal tunnel è una corrispondenza di destinazione. Una stazione di lavoro che deve usare il tunnel solo per un servizio è entrambe le cose, e quell’intersezione è il caso che la maggior parte del firmware consumer gestisce male.
Scrivi il requisito come coppia prima di confrontare i prodotti. È quella coppia che testerai più avanti.
Un prodotto che offre un elenco di dispositivi o un elenco globale di destinazioni forse non riesce a esprimere «solo questo dispositivo, solo queste destinazioni». La differenza non è estetica: una regola globale di destinazione manda il traffico di ogni dispositivo verso quel sito attraverso il tunnel, e una regola di dispositivo manda tutto il traffico di quel dispositivo. Nessuna delle due è il requisito. Prova quel caso con due dispositivi prima di fidarti dello schermo.
Costruisci la regola come intersezione
Una tabella tiene il progetto onesto. Metti lo scenario a sinistra, poi nomina separatamente la corrispondenza del mittente e quella della destinazione:
| Scenario | Sender match | Target match | Rule shape |
|---|---|---|---|
| Media player uses the tunnel | Player address | Any internet destination except the LAN | Source only |
| Office prefix reachable | Authorized LAN devices | 10.40.0.0/16 | Target only |
| One app on one laptop | Laptop address | The service address set | Source and target |
| Guest network never tunnels | Guest subnet | Any | Deny, evaluated first |
La terza riga è quella interessante, perché richiede entrambe le metà insieme. Se il firmware può esprimere solo un asse, il requisito va diviso in due regole o spostato su un dispositivo che sia in grado di farlo.
Mantieni stabile l’identità dell’origine. Una prenotazione DHCP, un segmento dedicato o un meccanismo di identità del dispositivo funzionano, ma un indirizzo che cambia alla scadenza del lease no. Includi IPv6, perché un indirizzo IPv4 non identifica tutto il traffico di un dispositivo.
La priorità decide la sovrapposizione
La sovrapposizione di regole è normale. Una regola ampia di dispositivo e una regola stretta di destinazione possono descrivere lo stesso flusso, e l’ordine di priorità documentato decide quale vince. Una schermata di impostazioni accattivante non ti dice quell’ordine.
Leggi il manuale per l’ordine e per il caso senza corrispondenza, poi prova entrambi con traffico che puoi osservare:
ip rule show
ip route get 203.0.113.10
Se la documentazione non indica l’ordine, presumi che la regola più stretta possa non vincere e progetta di conseguenza. Due regole che non possono entrare in conflitto sono più facili da supportare di un’unica regola furba con precedenza non documentata.
I nomi hanno bisogno di una politica di aggiornamento
Una destinazione scritta come dominio aggiunge un problema di manutenzione. Il router deve risolverla, aggiornare la mappatura, gestire più indirizzi e sottodomini e fare i conti con il DNS delle applicazioni che aggira il resolver previsto.
Copiare un singolo risultato di ricerca in una regola IP è un’istantanea, non una politica di dominio.
Decidi quanto può invecchiare una risposta prima che la regola sia sbagliata, e che cosa fa il router quando la risoluzione fallisce. Una regola che conserva l’ultimo indirizzo noto può sopravvivere a una migrazione di servizio; una regola che scarta la voce può fermare silenziosamente il tunneling. Entrambi i comportamenti sono accettabili se sono annotati accanto alla regola.
Definisci lo stato non disponibile
Una preferenza di rotta non impone traffico solo VPN. Quando il tunnel è inattivo, il router può bloccare il flusso, inviarlo diretto o usare un altro tunnel, e ogni scelta ha una firma di guasto diversa.
Decidi quale serve al requisito, poi verificalo fermando il tunnel e osservando il flusso:
curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10
Il traffico originato dal router stesso è un ambito separato. L’inoltro DNS, i controlli degli aggiornamenti e il monitoraggio possono avviare nuovi flussi dal router stesso invece di ereditare la corrispondenza di origine del dispositivo. Tieni conto esplicitamente di quei flussi, altrimenti appariranno come fughe inspiegate nei registri.