TAP senza ponte: un segmento virtuale con un uplink instradato
Un dispositivo TAP è un segmento Ethernet, non un ponte. Dagli un indirizzo, instrada tra esso e il prefisso dell’ufficio, e mantieni deliberata l’ampiezza di broadcast.
TAP consegna i frame Ethernet al sistema operativo, che è più capacità di quanta ne serva alla maggior parte dei progetti di accesso remoto e meno di un ponte. Il kernel può indirizzarlo, instradare attraverso di esso e proteggerlo con un firewall senza collegarlo a nessun segmento fisico. Vale la pena capire prima questa disposizione: un segmento Ethernet virtuale isolato il cui server agisce come router verso una LAN reale. Dà comportamento di secondo livello dentro il tunnel e inoltro IP ordinario fuori, che sono due promesse diverse. Il resto è la costruzione, la rotta, il percorso di ritorno e il rollback.
Costruisci il segmento isolato
Su Linux l’interfaccia richiede tre comandi: creala, attivala, dalle un indirizzo dentro il segmento che intendi. Scegli un prefisso che non entri in collisione con la LAN dell’ufficio e scrivilo, perché la collisione è invisibile finché non risponde un host che non dovrebbe esistere.
ip tuntap add dev tap0 mode tap
ip link set tap0 up
ip addr add 10.77.0.1/24 dev tap0
Niente qui richiede un ponte, e niente impedisce di aggiungerne uno in seguito. La documentazione del kernel su TUN/TAP descrive l’interfaccia stessa; l’appartenenza al ponte e la politica di inoltro sono decisioni separate che prendi dopo.
Instrada oltre il confine
Abilita l’inoltro, consenti i due prefissi nella catena di inoltro, e aggiungi una rotta verso il prefisso dell’ufficio con il router della LAN come salto successivo. Il lato VPN invia allora il traffico verso l’ufficio al server come suo gateway, e il server inoltra quei pacchetti come se stesso, non come un ponte. Un’interfaccia TAP con l’inoltro disabilitato è un segmento che risponde localmente e non raggiunge nulla oltre, che è il consueto stato a metà. Controlla poi i contatori dell’interfaccia su entrambi i lati, perché un contatore di ricezione che sale con un contatore di trasmissione piatto sul lato LAN significa una caduta nella catena di inoltro, non una rotta sbagliata.
Scrivi la rotta e la regola del firewall come un’unica modifica, perché ciascuna da sola produce uno stato che dal lato del client sembra un guasto di instradamento.
Decidi il percorso di ritorno
O il router della LAN apprende una rotta di ritorno verso il prefisso VPN, oppure il server traduce gli indirizzi di origine in uscita. La traduzione rende banale il percorso di ritorno e distrugge l’identità dell’origine, quindi i log di destinazione mostreranno l’indirizzo del server per ogni client dietro di esso. Un prefisso instradato conserva l’identità e richiede una modifica su apparecchiature che forse non gestisci.
Scegli deliberatamente e non in base a quale sia più rapido da digitare. Un solo prefisso instradato è di solito più pulito della traduzione, e la traduzione è di solito meglio che insegnare a un router non gestito un nuovo prefisso per un solo laboratorio.
Mantieni deliberata l’ampiezza di broadcast
Dentro il segmento virtuale, DHCP, scoperta e annuncio dei vicini si comportano come su uno switch, perché è un solo collegamento. Oltre il confine instradato non lo fanno, quindi il DHCP dell’ufficio e la scoperta dei servizi hanno bisogno di un progetto esplicito e non del presupposto che TAP li implichi. Il tipo di interfaccia non è un relè per servizi che vivono altrove.
Questa è la ragione onesta per scegliere TAP: qualcosa sul segmento virtuale ha bisogno di un comportamento locale al collegamento. Se niente ne ha bisogno, un dispositivo TUN con un prefisso instradato è più piccolo, e c’è meno da spiegare quando si rompe.
Verifica, poi scrivi il rollback
Da un client VPN, fai ping al router della LAN, fai ping a un host, e apri un servizio che conta su TCP. Poi controlla i contatori e la catena di inoltro, perché una caduta per politica da lontano sembra esattamente una rotta mancante. Il rollback è l’inverso della costruzione e appartiene al registro delle modifiche prima di iniziare: rimuovi la rotta, rimuovi l’indirizzo, elimina l’interfaccia.
Se il requisito è davvero un segmento Ethernet che copre due sedi, un ponte è la risposta onesta e un progetto diverso con un raggio d’impatto diverso. Se il requisito è la raggiungibilità, il segmento isolato con un uplink instradato fa il lavoro con meno spiegazioni dopo.