Ponte TAP isolato tra due schede tramite OpenVPN

Due schede di sviluppo devono condividere un solo segmento Ethernet mentre le loro panche si trovano in edifici diversi. Il tunnel esiste già e trasporta già Ethernet, quindi il lavoro restante sembra tre comandi e non lo è. Cosa fa l’host con un frame pontato, dove appartiene l’indirizzo del PC stesso e quale confine il ponte non crea sono tre fatti separati, e sbagliare il secondo è la ragione abituale per cui un laboratorio funziona a intermittenza e il suo accesso di gestione peggiora in silenzio. Nessuno di questi tre fatti è visibile in uno schema di topologia.

Il percorso sotto presuppone una connessione TAP autenticata tra due PC Linux, una porta cablata dedicata per panca e un’interfaccia di gestione che non fa parte dell’esperimento. L’ordine conta: prima i frame, poi gli indirizzi, infine il confine.

Cosa sposta davvero il ponte

Un ponte è uno switch implementato nel software. Impara quale indirizzo MAC compare dietro quale porta membro e inoltra i frame tra i membri senza consultare una tabella di routing IP. Nulla in quella descrizione comprende una sottorete, un gateway o una rotta predefinita, per questo abilitare l’inoltro IP non produce questo collegamento e per questo un ping può riuscire mentre altro traffico continua a fallire. Una scheda può raggiungere la sua compagna senza alcuna rotta predefinita configurata, cosa che sorprende chi si aspetta che il livello due si comporti come il livello tre.

Ogni PC aggiunge una porta cablata al ponte e il dispositivo TAP allo stesso ponte, quindi un frame da una scheda entra nella porta locale, viene inoltrato al dispositivo TAP, attraversa il tunnel, arriva sul dispositivo TAP della compagna e viene inoltrato verso la scheda della compagna. Il tunnel è una porta membro come qualsiasi altra, e il ponte non sa né gli importa che dietro ci sia una VPN. È questa simmetria a rendere l’esempio facile da ragionare: ogni lato ha una porta rivolta al laboratorio e una porta tunnel, e nessun lato è speciale.

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

I nomi identici sui due PC sono nomi locali, non oggetti condivisi. C’è un solo percorso Ethernet tra le panche, senza un secondo cavo e senza un secondo tunnel che chiuda un anello; un ponte che vede lo stesso MAC arrivare su due porte inoltrerà volentieri in cerchio.

Indirizzate il ponte, non le sue porte membro

L’identità del PC sul segmento del laboratorio appartiene al dispositivo ponte. Le porte membro restano senza numero, perché una porta è un membro che inoltra e un indirizzo su di essa creerebbe un secondo proprietario concorrente dello stesso segmento. È la correzione che la maggior parte delle ricette fatte a mano sbaglia: indirizzano il dispositivo TAP e il ponte, e poi si chiedono quale dei due raggiunga davvero la compagna.

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

La compagna usa la stessa forma con un altro indirizzo host, e le schede prendono indirizzi nello stesso intervallo usando l’indirizzo del ponte del PC come salto successivo se ne hanno bisogno. Usate intervalli di documentazione finché il piano non è concordato, e riservate l’intervallo perché non entri in collisione con ciò che l’ufficio già instrada. Prima di eseguire qualsiasi parte, confermate che le porte membro non portino indirizzi residui, client DHCP o appartenenza a un altro ponte, e allineate l’indirizzamento del dispositivo TAP tramite ciò che possiede la configurazione del tunnel perché non ripristini un indirizzo più tardi.

Perché una porta dedicata per panca

Una porta cablata dedicata è ciò che impedisce all’esperimento di diventare una modifica a livello di ufficio. L’interfaccia di gestione porta SSH, la rotta predefinita e la connessione VPN esterna, e nulla di tutto ciò appartiene a un ponte il cui scopo è spostare frame di laboratorio.

Collegare un adattatore di gestione mette la LAN dell’ufficio a una decisione di inoltro da una scheda di sviluppo, e una scheda che si comporta male al livello due è esattamente il tipo di dispositivo che non volete su quel segmento. Un adattatore Wi-Fi è peggio: il bridging di un’interfaccia wireless in modalità infrastruttura non si comporta come il bridging Ethernet, e il guasto è confuso invece che pulito.

Tenete l’intervallo del laboratorio fuori da qualsiasi ambito DHCP di produzione. Se le schede avranno poi bisogno di indirizzamento dinamico, un solo assegnatore autorizzato con un solo pool è l’unica disposizione che resta prevedibile; i router ordinari di due sedi che rispondono sullo stesso segmento producono indirizzi che nessuno sa spiegare.

Il confine che il ponte non crea

Il bridging non è routing, e non è nemmeno isolamento. I frame che attraversano il ponte possono ancora raggiungere gli hook di filtraggio dell’host, a seconda del percorso bridge-netfilter installato, quindi la politica effettiva va ispezionata e non presunta. Disattivare il firewall perché è andato perso un frame scambia un bug specifico con uno generale.

L’inoltro IP tra il ponte e ogni interfaccia di gestione o di uplink dovrebbe restare spento o essere negato esplicitamente, e questo è un controllo separato dall’appartenenza al ponte. Una scheda che sceglie l’indirizzo di laboratorio del PC come gateway verifica esattamente questo: se il transito di gestione riesce, il confine che intendevate non c’era mai.

Altre due famiglie meritano una decisione esplicita. Il piano di indirizzamento non rende il ponte solo IPv4, quindi IPv6 e gli altri EtherType hanno bisogno del proprio piano o filtro. E un ping riuscito non dice nulla sul fatto che i broadcast di scoperta della scheda, i gruppi multicast o i frame jumbo attraverseranno il percorso, perché sono classi di traffico diverse con valori predefiniti diversi.

Infine, trasporto e riservatezza sono due acquisti diversi. TAP trasporta Ethernet; il servizio OpenVPN fornisce la protezione attorno. Un overlay VXLAN trasporta anch’esso Ethernet e non fornisce alcuna riservatezza da solo, quindi sostituire l’uno con l’altro cambia le proprietà di sicurezza anche quando lo schema di topologia sembra identico.

Persistenza e i test che la dimostrano

Un comando digitato una volta dopo il collegamento non è una configurazione. Rendete persistenti il ponte, l’appartenenza delle porte e l’unico indirizzo host tramite il gestore di rete esistente del PC, e legate il collegamento alla comparsa del dispositivo TAP perché una riconnessione non lasci un ponte con un membro scomparso.

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

Poi provate ciò di cui le schede hanno davvero bisogno in entrambe le direzioni, ricollegate il tunnel e riavviate un PC secondo il piano di ripristino approvato. Confermate tre cose dopo: l’accesso di gestione funziona ancora in modo indipendente, non compare alcun indirizzo di laboratorio duplicato e nessuna interfaccia di produzione inattesa si è unita al ponte. Quella combinazione è la prova che l’esperimento è rimasto dentro la sua panca.