VPN instradata o in bridge: scegli in base a ciò che il client deve raggiungere

Lo stesso giorno arrivano due ticket: un utente ha bisogno di un’applicazione web interna e un ingegnere ha bisogno che uno strumento da banco si comporti come se fosse sullo stesso segmento Ethernet. A entrambi si risponde con metteteli sulla VPN, ed è lì che iniziano i guai. Un tunnel instradato e un tunnel in bridge estendono relazioni diverse, e solo una delle due si adatta a ogni richiesta. Scegliere la topologia è una decisione di accesso, non un’impostazione di crittografia.

Due richieste che allo sportello sembrano uguali

Il requisito del dipendente è un servizio, raggiungibile via IP, da un dispositivo che non controlli. Il requisito dell’ingegnere è a livello di collegamento: lo strumento si aspetta di vedere frame Ethernet e scoperta in broadcast, e forse DHCP dal segmento in cui crede di trovarsi.

Sono domande diverse, e rispondere a entrambe con un bridge amplia senza motivo l’accesso del dipendente all’intera LAN dell’ufficio.

Scrivi il requisito come frase prima di scegliere: quali destinazioni, quali protocolli e quali peer devono sembrare locali. Se la risposta è un host e una porta, l’instradamento la copre. Se la risposta è una relazione a livello di frame con dispositivi che parlano solo in broadcast, il bridge può essere l’unica opzione. Tutto ciò che sta in mezzo merita un segmento di prova invece della LAN di produzione.

Una rotta è più stretta dell’appartenenza alla LAN

Un client instradato riceve un indirizzo su una sottorete del tunnel e rotte per i prefissi che scegli. Può raggiungere il server applicativo e nient’altro, se è ciò che dice la policy. Il gateway diventa il punto di applicazione, purché ogni percorso rilevante lo attraversi.

Non confondere una rotta con un permesso. Dire a un client come raggiungere una sottorete non gli impedisce di tentare un’altra destinazione.

Applica il controllo degli accessi dove può davvero imporre il flusso, e mantieni i permessi dell’applicazione stessa. Una regola di inoltro ampia o una seconda interfaccia dimenticata possono concedere più di quanto suggerisca il diagramma. Leggi le regole effettive, non quelle previste. Poi prova una destinazione che dovrebbe fallire, perché una policy che nessuno ha tentato di violare è un’ipotesi.

Un bridge cambia la domanda di ammissione

Il bridging combina un’interfaccia fisica e un dispositivo TAP in uno switch software, così i dispositivi remoti si uniscono allo stesso dominio broadcast. È una capacità reale e un rischio reale: il dispositivo remoto non è più un ospite instradato, è un partecipante.

Decidi quali dispositivi possono unirsi, quali tipi di frame devono attraversare e dove viene bloccata l’interazione indesiderata. Indirizzamento e autorità DHCP diventano parte della rete condivisa, e due server DHCP su un segmento producono esattamente il caos che ti aspetti.

Per lo strumento, un segmento di prova dedicato di solito si adatta meglio della LAN dell’ufficio. Tieni l’accesso di gestione fuori dall’esperimento, e definisci come viene rimosso il partecipante temporaneo quando il lavoro finisce.

Il filtraggio esiste in entrambe le topologie

Un bridge non è intrinsecamente non filtrabile, e una rotta non è intrinsecamente sicura. Il filtraggio dei bridge di Linux ha i suoi hook e la sua sintassi di regole, e una regola scritta per l’inoltro IP instradato non si applica automaticamente ai frame in bridge.

Controlla cosa supporta davvero la piattaforma prima di promettere un confine:

bridge link show
nft list ruleset

TUN e TAP descrivono il traffico dell’interfaccia, non la cifratura. Cambiare interfaccia non risolve nulla di tutto ciò: l’autenticazione dei peer, una chiave rubata e una policy crittografica obsoleta sopravvivono tutte al cambiamento. Entrambe le estremità hanno ancora bisogno di impostazioni che corrispondano e che siano ancora supportate.

Dimostra il confine con tre tentativi

L’accettazione è tre osservazioni, non una revisione del diagramma. L’operazione richiesta deve funzionare, una destinazione non correlata deve fallire, e i servizi di gestione del gateway stesso devono restare fuori portata.

Esegui il percorso consentito e quello negato dallo stesso client, e registra entrambi:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

Per un bridge, aggiungi i controlli a livello di collegamento: se il traffico di scoperta consentito attraversa, se l’indirizzamento proviene dall’autorità prevista e se il partecipante temporaneo è sparito dopo la rimozione. Quando l’IP instradato semplice soddisfa già il requisito, unirsi al segmento Ethernet dell’ufficio richiede una giustificazione separata, e va scritta prima del cambiamento.