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:

ScenarioSender matchTarget matchRule shape
Media player uses the tunnelPlayer addressAny internet destination except the LANSource only
Office prefix reachableAuthorized LAN devices10.40.0.0/16Target only
One app on one laptopLaptop addressThe service address setSource and target
Guest network never tunnelsGuest subnetAnyDeny, 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.

Articoli correlati