Prima il gateway della VLAN, poi la decisione di uscita VPN

Due VLAN necessitano di uscite VPN diverse, e la prima domanda non è quale politica scrivere ma quale dispositivo risponde al gateway predefinito. Se uno switch instrada tra le VLAN, una regola del firewall può descrivere un percorso che i pacchetti non prendono mai. Ripercorrete la topologia prima di toccare la politica di uscita.

Primo passo: trovate il gateway che usa ogni VLAN

Chiedete a ogni client il suo gateway e chiedete allo switch quale interfaccia possiede la VLAN. Il gateway predefinito determina la prima decisione di routing per il traffico che lascia la sottorete, quindi determina anche quale dispositivo può applicare una politica.

ip route show default
show ip interface brief

Sono comuni due disposizioni coerenti. Il firewall possiede le interfacce VLAN e instrada tra di esse; oppure lo switch multilayer le possiede e instrada localmente, inviando solo le destinazioni esterne al firewall. Entrambe funzionano e collocano la politica in punti diversi.

Sceglietene una deliberatamente, perché una disposizione mista è il modo in cui le regole finiscono sul dispositivo sbagliato.

Secondo passo: decidete dove vive la politica locale

Se lo switch instrada tra personale e laboratorio, una regola del firewall non può ispezionare uno scambio che non raggiunge mai il firewall. La politica locale deve vivere nei controlli di accesso dello switch stesso, oppure il traffico deve essere indirizzato di proposito attraverso un punto di ispezione.

Anche la scelta inversa ha un costo. Fare del firewall il gateway di ogni VLAN mette il traffico instradato localmente nel piano di capacità e disponibilità di quell'apparecchio, così un riavvio del firewall diventa un'interruzione tra VLAN. Valutate l'hardware reale invece di supporre che gli switch siano senza stato o che i firewall siano lenti. La pianificazione della capacità è più facile quando il dispositivo che riavviate non è anche il percorso tra due sottoreti occupate.

Ciò che conta è se la politica scelta si trova sul percorso che i pacchetti seguono davvero.

Terzo passo: date ai due dispositivi un solo transito

Quando lo switch instrada, una sola sottorete di transito mantiene la topologia leggibile, invece di appendere entrambi i dispositivi a ogni VLAN client come router rivali. Lo switch possiede le sottoreti client e il firewall possiede l'esterno.

# on the switch
ip route 0.0.0.0/0 10.255.0.2
# on the firewall
ip route add 10.20.10.0/24 via 10.255.0.1
ip route add 10.20.20.0/24 via 10.255.0.1

Lo switch invia le destinazioni esterne all'indirizzo di transito del firewall, e il firewall ha rotte di ritorno verso entrambi i prefissi client attraverso lo switch. Mantenete intatti l'accesso di gestione, le impostazioni del gateway DHCP e l'appartenenza alla VLAN durante la migrazione, perché sono quelle tre cose a trasformare un passaggio pulito in un pomeriggio con un cavo console.

Una progettazione a transito rende anche la prossima sostituzione del firewall un cambio di routing invece di un progetto di ricablaggio.

Quarto passo: scegliete l'uscita in base alla sorgente che arriva

Con routing ordinario e senza traduzione della sorgente in mezzo, il firewall riceve l'indirizzo originale del personale o del laboratorio sull'interfaccia di transito. Entrambe le VLAN arrivano su un solo collegamento, e le loro identità IP lo sopravvivono.

Esprimete la scelta della VPN con quell'indirizzo di origine e le destinazioni previste sul percorso di ingresso reale. La documentazione delle regole di OPNsense distingue un'impostazione di gateway predefinito, che segue il routing di sistema, da un gateway esplicito, che invoca il routing basato su policy. Usate la forma esplicita quando la scelta dipende da dove è arrivato il pacchetto. Una normale rotta predefinita non ha alcun motivo di guardare la sorgente.

Tenete le destinazioni locali fuori da una regola di uscita troppo ampia, e verificate il modello di gateway supportato per la versione che eseguite.

Quinto passo: dimostrate entrambi i percorsi

Scrivete il risultato come due frasi: il traffico del personale verso destinazioni approvate esce dall'uscita A, e il traffico del laboratorio verso destinazioni approvate esce dall'uscita B. Aggiungete le rotte di ritorno, le regole di traduzione e il comportamento previsto quando un'uscita è inattiva.

traceroute -n 198.51.100.10

Poi provate separatamente un servizio locale tra VLAN, perché esercita una decisione diversa nello stesso progetto.

Un flusso nuovo da ogni VLAN, un servizio locale funzionante e un percorso di guasto documentato dimostrano insieme il progetto; un solo ping riuscito dimostra soltanto che in quel momento esisteva un percorso.