Ponte TAP illada entre dúas placas mediante OpenVPN

Dúas placas de desenvolvemento deben compartir un único segmento Ethernet mentres os seus bancos están en edificios distintos. O túnel xa existe e xa transporta Ethernet, así que o traballo restante parece tres comandos e non o é. Que fai o host cunha trama pontada, onde pertence o enderezo propio do equipo e que fronteira non crea a ponte son tres feitos separados, e equivocarse no segundo é a razón habitual de que un laboratorio funcione de forma intermitente e o seu acceso de xestión se degrade en silencio. Ningún deses tres feitos é visible nun diagrama de topoloxía.

O camiño de abaixo supón unha conexión TAP autenticada entre dous equipos Linux, un porto cableado dedicado por banco e unha interface de xestión que non forma parte do experimento. A orde importa: primeiro as tramas, despois os enderezos, por último a fronteira.

Que move realmente a ponte

Unha ponte é un conmutador implementado en software. Aprende que enderezo MAC aparece detrás de que porto membro e reenvía tramas entre membros sen consultar unha táboa de encamiñamento IP. Nada nesa descrición inclúe unha subrede, unha pasarela nin unha ruta por defecto, por iso habilitar o reenvío IP non produce esta conexión e por iso un ping pode ter éxito mentres outro tráfico segue fallando. Unha placa pode alcanzar a súa compañeira sen ningunha ruta por defecto configurada, algo que sorprende a quen espera que a capa dous se comporte como a capa tres.

Cada equipo achega un porto cableado á ponte e o dispositivo TAP á mesma ponte, así que unha trama dunha placa entra polo porto local, reenvíase ao dispositivo TAP, cruza o túnel, chega ao dispositivo TAP do compañeiro e reenvíase cara á placa do compañeiro. O túnel é un porto membro como calquera outro, e á ponte non lle consta nin lle importa que detrás haxa unha VPN. Esa simetría é o que fai fácil razoar sobre o exemplo: cada lado ten un porto orientado ao laboratorio e un porto de túnel, e ningún é especial.

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

Os nomes idénticos en ambos os equipos son nomes locais, non obxectos compartidos. Hai un só camiño Ethernet entre os bancos, sen un segundo cable e sen un segundo túnel que peche un bucle; unha ponte que ve a mesma MAC chegar por dous portos reenviará encantada en círculos.

Enderezar a ponte, non os seus portos membros

A identidade do equipo no segmento do laboratorio pertence ao dispositivo ponte. Os portos membros quedan sen numerar, porque un porto é un membro de reenvío e un enderezo sobre el crearía un segundo propietario competidor do mesmo segmento. Esta é a corrección que a maioría das receitas feitas a man fan mal: enderezan o dispositivo TAP e a ponte, e logo pregúntanse a cal dos dous chega realmente o compañeiro.

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

O compañeiro usa a mesma forma con outro enderezo de host, e as placas toman enderezos do mesmo rango co enderezo da ponte do equipo como o seu seguinte salto se necesitan un. Use rangos de documentación ata que se acorde o plan, e reserve o rango para que non choque con nada que a oficina xa encamiñe. Antes de executar calquera parte, confirme que os portos membros non levan ningún enderezo sobrante, ningún cliente DHCP e ningunha pertenza a outra ponte, e concilie o enderezo do dispositivo TAP a través do que posúa a configuración do túnel para que non restaure un enderezo máis tarde.

Por que un porto dedicado por banco

Un porto cableado dedicado é o que evita que o experimento se converta nun cambio para toda a oficina. A interface de xestión leva SSH, a ruta por defecto e a conexión VPN exterior, e nada diso pertence a unha ponte cuxo propósito é mover tramas de laboratorio.

Conectar un adaptador de xestión pon a LAN da oficina a unha decisión de reenvío de distancia dunha placa de desenvolvemento, e unha placa que se porta mal na capa dous é exactamente o tipo de dispositivo que non quere nese segmento. Un adaptador Wi-Fi é peor: pontar unha interface sen fíos en modo infraestrutura non se comporta como pontar Ethernet, e o fallo resulta confuso en lugar de limpo.

Manteña o rango do laboratorio fóra de calquera ámbito DHCP de produción. Se as placas necesitan máis adiante enderezo dinámico, un único asignador autorizado cun único grupo é a única disposición que segue sendo predicible; os routers correntes de dúas sedes que responden no mesmo segmento producen enderezos que ninguén pode explicar.

A fronteira que a ponte non crea

Pontar non é encamiñar, e tampouco é illamento. As tramas que cruzan a ponte poden seguir chegando aos ganchos de filtrado do host, segundo a ruta de bridge-netfilter instalada, así que a política efectiva debe inspeccionarse en lugar de supoñerse. Desactivar a devasa porque se perdeu unha trama cambia un fallo concreto por un xeral.

O reenvío IP entre a ponte e cada interface de xestión ou de enlace ascendente debería permanecer desactivado ou denegarse explicitamente, e iso é un control separado da pertenza á ponte. Unha placa que escolle o enderezo de laboratorio do equipo como a súa pasarela proba exactamente isto: se o tránsito de xestión ten éxito, a fronteira que pretendía nunca estivo alí.

Dúas familias máis merecen unha decisión explícita. O plan de enderezamento non fai que a ponte sexa só IPv4, así que IPv6 e outros EtherTypes necesitan o seu propio plan ou filtro. E un ping correcto non di nada sobre se as difusións de descuberta da placa, os grupos multicast ou as tramas jumbo atravesarán o camiño, porque son clases de tráfico distintas con valores por defecto distintos.

Por último, transporte e confidencialidade son dúas compras distintas. TAP transporta Ethernet; o servizo OpenVPN achega a protección ao redor. Unha superposición VXLAN tamén transporta Ethernet e non achega confidencialidade por si soa, así que substituír unha pola outra cambia as propiedades de seguridade mesmo cando o diagrama de topoloxía parece idéntico.

Persistencia e as probas que a demostran

Un comando escrito unha vez tras conectarse non é unha configuración. Faga persistentes a ponte, a pertenza de portos e o único enderezo de host a través do xestor de rede existente do equipo, e ligue a conexión á aparición do dispositivo TAP para que unha reconexión non deixe unha ponte cun membro desaparecido.

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

Despois probe o que necesitan realmente as placas en ambos os sentidos, reconecte o túnel e reinicie un equipo segundo o plan de recuperación aprobado. Confirme tres cousas despois: o acceso de xestión segue funcionando de forma independente, non aparece ningún enderezo de laboratorio duplicado e ningunha interface de produción inesperada se uniu á ponte. Esa combinación é a proba de que o experimento quedou dentro do seu banco.