Izolita TAP-ponto inter du tabuloj per OpenVPN

Du evoluigaj tabuloj devas kunhavigi unu Ethernet-segmenton, dum iliaj benkoj staras en malsamaj konstruaĵoj. La tunelo jam ekzistas kaj jam transportas Ethernet, do la resta laboro aspektas kiel tri komandoj kaj ne estas. Kion la gastigo faras kun pontigita kadro, kie apartenas la propra adreso de la komputilo kaj kiun limon la ponto ne kreas, estas tri apartaj faktoj, kaj erari pri la dua estas la kutima kialo, ke laboratorio funkcias intermita kaj ĝia administra aliro silente malboniĝas. Neniu el tiuj tri faktoj videblas en topologia diagramo.

La suba vojo supozas aŭtentikigitan TAP-konekton inter du Linuksaj komputiloj, unu dediĉitan kablan pordon por benko kaj administran interfacon, kiu ne estas parto de la eksperimento. La ordo gravas: unue kadroj, due adresoj, laste la limo.

Kion la ponto efektive movas

Ponto estas ŝaltilo efektivigita en programaro. Ĝi lernas, kiu MAC-adreso aperas malantaŭ kiu membra pordo, kaj plusendas kadrojn inter membroj sen konsulti IP-enkursigan tabelon. Nenio en tiu priskribo enhavas subreton, enirejon aŭ defaŭltan vojon, tial ŝalti IP-plusendadon ne produktas ĉi tiun ligon kaj tial ping povas sukcesi dum alia trafiko ankoraŭ malsukcesas. Tabulo povas atingi sian partneron tute sen agordita defaŭlta vojo, kio surprizas homojn, kiuj atendas, ke tavolo du kondutu kiel tavolo tri.

Ĉiu komputilo kontribuas unu kablan pordon al la ponto kaj la TAP-aparaton al la sama ponto, do kadro de tabulo eniras la lokan pordon, estas plusendita al la TAP-aparato, transiras la tunelon, alvenas ĉe la TAP-aparato de la partnero kaj estas plusendita al la tabulo de la partnero. La tunelo estas membra pordo kiel ĉiu alia, kaj la ponto ne scias nek zorgas, ke malantaŭ ĝi staras VPN. Ĝuste tiu simetrio faras la ekzemplon facile pripensebla: ĉiu flanko havas unu laboratorian pordon kaj unu tunelan pordon, kaj neniu flanko estas speciala.

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

La identaj nomoj sur ambaŭ komputiloj estas lokaj nomoj, ne kunhavataj objektoj. Inter la benkoj ekzistas unu Ethernet-vojo, sen dua kablo kaj sen dua tunelo fermanta buklon; ponto, kiu vidas la saman MAC alveni sur du pordoj, ĝoje plusendos en cirkloj.

Adresu la ponton, ne ĝiajn membrajn pordojn

La identeco de la komputilo en la laboratoria segmento apartenas al la ponta aparato. Membraj pordoj restas sen numeroj, ĉar pordo estas plusenda membro kaj adreso sur ĝi kreus duan, konkurantan posedanton de la sama segmento. Tio estas la korekto, kiun plej multaj permane verkitaj receptoj maltrafas: ili adresas la TAP-aparaton kaj la ponton, kaj poste demandas, kiun el la du la partnero efektive atingas.

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 partnero uzas la saman formon kun malsama gastiga adreso, kaj la tabuloj prenas adresojn en la sama gamo uzante la pontan adreson de la komputilo kiel sian sekvan salton, se ili bezonas unu. Uzu dokumentajn gamojn ĝis la plano estos interkonsentita, kaj rezervu la gamon tiel, ke ĝi ne koliziu kun io, kion la oficejo jam enkursigas. Antaŭ ol lanĉi ion el tio, konfirmu, ke la membraj pordoj portas neniun restan adreson, neniun DHCP-klienton kaj neniun membrecon en alia ponto, kaj akordu la adresadon de la TAP-aparato per tio, kio posedas la tunelan agordon, por ke ĝi ne restarigu adreson poste.

Kial unu dediĉita pordo por benko

Dediĉita kabla pordo estas tio, kio malhelpas la eksperimenton fariĝi oficej-skala ŝanĝo. La administra interfaco portas SSH, la defaŭltan vojon kaj la eksteran VPN-konekton, kaj nenio el tio apartenas al ponto, kies celo estas movi laboratoriajn kadrojn.

Konekti administran adaptilon metus la oficejan LAN unu plusenda decido for de evoluiga tabulo, kaj tabulo, kiu miskondutas ĉe tavolo du, estas ĝuste tiu speco de aparato, kiun vi ne volas en tiu segmento. Wi-Fi-adaptilo estas pli malbona: pontigi sendratan interfacon en infrastruktura reĝimo kondutas ne kiel pontigi Ethernet, kaj la fiasko estas konfuza anstataŭ pura.

Tenu la laboratorian gamon ekster ĉiu produktada DHCP-kampo. Se la tabuloj poste bezonos dinamikan adresadon, unu rajtigita asignanto kun unu baseno estas la sola aranĝo, kiu restas antaŭvidebla; ordinaraj enkursigiloj de du ejoj respondantaj en la sama segmento produktas adresojn, kiujn neniu povas klarigi.

La limo, kiun la ponto ne kreas

Pontigado ne estas enkursigado, kaj ĝi ankaŭ ne estas izolado. Kadroj, kiuj transiras la ponton, ankoraŭ povas atingi la filtrajn hokojn de la gastigo, depende de la instalita bridge-netfilter-vojo, do la efektiva politiko devas esti inspektita, ne supozita. Malŝalti la fajroŝirmilon ĉar unu kadro perdiĝis interŝanĝas specifan cimon kontraŭ ĝenerala.

IP-plusendado inter la ponto kaj ĉiu administra aŭ suprenliga interfaco devus resti malŝaltita aŭ esti eksplicite malpermesita, kaj tio estas aparta kontrolo de ponta membreco. Tabulo, kiu elektas la laboratorian adreson de la komputilo kiel sian enirejon, testas ĝuste tion: se administra trafiko sukcesas, la intencita limo neniam ekzistis.

Du pliaj familioj meritindas eksplicitan decidon. La adresa plano ne faras la ponton nur-IPv4, do IPv6 kaj aliaj EtherTypes bezonas sian propran planon aŭ filtrilon. Kaj sukcesa ping diras nenion pri tio, ĉu la malkovraj dissendoj, multicast-grupoj aŭ jumbo-kadroj de la tabulo trapasos la vojon, ĉar tiuj estas malsamaj trafikaj klasoj kun malsamaj defaŭltoj.

Fine, transporto kaj konfidenceco estas du malsamaj aĉetoj. TAP portas Ethernet; la OpenVPN-servo liveras la protekton ĉirkaŭ ĝi. VXLAN-tavolo ankaŭ portas Ethernet kaj liveras neniun konfidendecon per si mem, do anstataŭigi unu per la alia ŝanĝas la sekurecajn ecojn eĉ kiam la topologia diagramo aspektas identa.

Daŭreco kaj la testoj, kiuj pruvas ĝin

Komando tajpita unufoje post konekto ne estas agordo. Daŭrigu la ponton, la pordan membrecon kaj la solan gastigan adreson per la ekzistanta retadministrilo de la komputilo, kaj ligiĝu la konekton al la apero de la TAP-aparato, por ke rekonekto ne lasu ponton kun malaperinta membro.

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

Poste testu, kion la tabuloj efektive bezonas en ambaŭ direktojn, rekonektu la tunelon kaj restartigu unu komputilon laŭ la aprobita restaŭra plano. Konfirmu tri aferojn poste: la administra aliro ankoraŭ funkcias sendepende, neniu duobla laboratoria adreso aperas, kaj neniu neatendita produktada interfaco aliĝis al la ponto. Tiu kombino estas la pruvo, ke la eksperimento restis en sia benko.