Pont TAP aïllat entre dues plaques a través d’OpenVPN

Dues plaques de desenvolupament han de compartir un sol segment Ethernet mentre els seus bancs són en edificis diferents. El túnel ja existeix i ja transporta Ethernet, així que la feina restant sembla tres ordres i no ho és. Què fa l’amfitrió amb una trama que travessa el pont, on pertany l’adreça pròpia de l’ordinador i quina frontera no crea el pont són tres fets separats, i equivocar-se en el segon és el motiu habitual que un laboratori funcioni de manera intermitent i que el seu accés de gestió es degradi sense soroll. Cap d’aquests tres fets no és visible en un diagrama de topologia.

El camí següent assumeix una connexió TAP autenticada entre dos ordinadors Linux, un port cablejat dedicat per banc i una interfície de gestió que no forma part de l’experiment. L’ordre importa: primer les trames, després les adreces, finalment la frontera.

Què mou realment el pont

Un pont és un commutador implementat en programari. Aprèn quina adreça MAC apareix darrere de quin port membre i reenvia trames entre membres sense consultar cap taula d’encaminament IP. Res d’aquesta descripció no implica una subxarxa, una passarel·la ni una ruta per defecte, i per això activar el reenviament IP no produeix aquesta connexió i per això un ping pot tenir èxit mentre altre trànsit encara falla. Una placa pot arribar al seu company sense cap ruta per defecte configurada, cosa que sorprèn qui espera que la capa dos es comporti com la capa tres.

Cada ordinador aporta un port cablejat al pont i el dispositiu TAP al mateix pont, així que una trama d’una placa entra pel port local, es reenvia al dispositiu TAP, travessa el túnel, arriba al dispositiu TAP del company i es reenvia cap a la placa del company. El túnel és un port membre com qualsevol altre, i el pont no sap ni li importa que hi hagi una VPN al darrere. Aquesta simetria és el que fa l’exemple fàcil de raonar: cada costat té un port orientat al laboratori i un port de túnel, i cap costat no és especial.

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

Els noms idèntics als dos ordinadors són noms locals, no objectes compartits. Hi ha un sol camí Ethernet entre els bancs, sense cap segon cable ni cap segon túnel que tanqui un bucle; un pont que veu la mateixa MAC arribar per dos ports reenviarà encantat en cercles.

Adreceu el pont, no els seus ports membres

La identitat de l’ordinador al segment del laboratori pertany al dispositiu pont. Els ports membres queden sense numerar, perquè un port és un membre de reenviament i una adreça sobre ell crearia un segon propietari competitiu del mateix segment. Aquesta és la correcció que la majoria de receptes fetes a mà fan malament: adrecen el dispositiu TAP i el pont, i després es pregunten a quin dels dos arriba realment el company.

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

El company fa servir la mateixa forma amb una adreça d’amfitrió diferent, i les plaques prenen adreces del mateix rang amb l’adreça del pont de l’ordinador com a salt següent si en necessiten una. Feu servir rangs de documentació fins que el pla estigui acordat, i reserveu el rang perquè no xoqui amb res que l’oficina ja encamini. Abans d’executar res d’això, confirmeu que els ports membres no porten cap adreça sobrant, cap client DHCP ni cap pertinença a un altre pont, i reconcilieu l’adreçament del dispositiu TAP a través del que posseeixi la configuració del túnel perquè no restauri una adreça més tard.

Per què un port dedicat per banc

Un port cablejat dedicat és el que evita que l’experiment es converteixi en un canvi a escala de tota l’oficina. La interfície de gestió porta SSH, la ruta per defecte i la connexió VPN exterior, i res d’això no pertany a un pont el propòsit del qual és moure trames de laboratori.

Connectar un adaptador de gestió posa la LAN de l’oficina a una decisió de reenviament de distància d’una placa de desenvolupament, i una placa que es comporta malament a la capa dos és exactament el tipus de dispositiu que no voleu en aquest segment. Un adaptador Wi-Fi és pitjor: fer pont d’una interfície sense fil en mode infraestructura no es comporta com fer pont d’Ethernet, i la fallada és confusa en lloc de neta.

Manteniu el rang del laboratori fora de qualsevol àmbit DHCP de producció. Si les plaques més endavant necessiten adreçament dinàmic, un únic assignador autoritzat amb un únic pool és l’única disposició que es manté predictible; els encaminadors corrents de dos llocs que responen al mateix segment produeixen adreces que ningú no pot explicar.

La frontera que el pont no crea

Fer pont no és encaminar, i tampoc no és aïllament. Les trames que travessen el pont encara poden arribar als ganxos de filtratge de l’amfitrió, segons el camí de bridge-netfilter instal·lat, així que la política efectiva s’ha d’inspeccionar en lloc de suposar. Desactivar el tallafoc perquè una trama s’ha perdut canvia un error concret per un de general.

El reenviament IP entre el pont i cada interfície de gestió o d’enllaç ascendent hauria de quedar desactivat o ser denegat explícitament, i això és un control separat de la pertinença al pont. Una placa que tria l’adreça de laboratori de l’ordinador com a passarel·la prova exactament això: si el trànsit de gestió té èxit, la frontera que volíeu no hi era mai.

Dues famílies més mereixen una decisió explícita. El pla d’adreçament no fa que el pont sigui només IPv4, així que IPv6 i altres EtherTypes necessiten el seu propi pla o filtre. I un ping correcte no diu res sobre si les difusions de descobriment de la placa, els grups multicast o les trames jumbo travessaran el camí, perquè són classes de trànsit diferents amb valors per defecte diferents.

Finalment, transport i confidencialitat són compres diferents. TAP transporta Ethernet; el servei OpenVPN proporciona la protecció al seu voltant. Una superposició VXLAN també transporta Ethernet i no proporciona cap confidencialitat per si sola, així que substituir una per l’altra canvia les propietats de seguretat fins i tot quan el diagrama de topologia sembla idèntic.

Persistència i les proves que la demostren

Una ordre escrita una vegada després de connectar no és una configuració. Feu persistents el pont, la pertinença de ports i l’única adreça d’amfitrió a través del gestor de xarxa existent de l’ordinador, i lligueu la connexió a l’aparició del dispositiu TAP perquè una reconnexió no deixi un pont amb un membre desaparegut.

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

Després proveu què necessiten realment les plaques en totes dues direccions, torneu a connectar el túnel i reinicieu un ordinador segons el pla de recuperació aprovat. Confirmeu tres coses després: l’accés de gestió encara funciona de manera independent, no apareix cap adreça de laboratori duplicada i cap interfície de producció inesperada no s’ha unit al pont. Aquesta combinació és la prova que l’experiment s’ha quedat dins del seu banc.