Isoleret TAP-bro mellem to boards over OpenVPN

To udviklingsboards skal dele et Ethernet-segment, mens deres bænke står i forskellige bygninger. Tunnelen findes allerede og transporterer allerede Ethernet, så det resterende arbejde ser ud som tre kommandoer og er det ikke. Hvad værten gør med en broet ramme, hvor computerens egen adresse hører til, og hvilken grænse broen ikke skaber, er tre separate fakta, og at få det andet forkert er den sædvanlige grund til, at et laboratorium kører ujævnt, og dets administrationsadgang stille forringes. Ingen af de tre fakta er synlige i et topologidiagram.

Vejen nedenfor forudsætter en godkendt TAP-forbindelse mellem to Linux-computere, én dedikeret kablet port til hver bænk og en administrationsgrænseflade, der ikke er en del af forsøget. Rækkefølgen er vigtig: rammer først, adresser derefter, grænse til sidst.

Hvad broen faktisk flytter

En bro er en switch implementeret i software. Den lærer, hvilken MAC-adresse der viser sig bag hvilken medlemsport, og videresender rammer mellem medlemmer uden at konsultere en IP-routingtabel. Intet i den beskrivelse involverer et subnet, en gateway eller en standardrute, og derfor skaber aktivering af IP-videresendelse ikke denne tilslutning, og derfor kan en ping lykkes, mens anden trafik stadig fejler. Et board kan nå sin partner helt uden en konfigureret standardrute, hvilket overrasker folk, der forventer, at lag to opfører sig som lag tre.

Hver computer bidrager med én kablet port til broen og TAP-enheden til samme bro, så en ramme fra et board kommer ind på den lokale port, videresendes til TAP-enheden, krydser tunnelen, ankommer på partnerens TAP-enhed og videresendes ud til partnerens board. Tunnelen er en medlemsport som enhver anden, og broen ved ikke og er ligeglad med, at der ligger en VPN bag den. Den symmetri er det, der gør eksemplet let at ræsonnere om: hver side har én laboratorievent port og én tunnelport, og ingen side er speciel.

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

De identiske navne på begge computere er lokale navne, ikke delte objekter. Der er én Ethernet-vej mellem bænkene, uden et andet kabel og uden en anden tunnel, der lukker en løkke; en bro, der ser den samme MAC ankomme på to porte, videresender med glæde i ring.

Adressér broen, ikke dens medlemsporte

Computerens identitet på laboratorie-segmentet hører til broenheden. Medlemsportene forbliver unummererede, fordi en port er et videresendende medlem, og en adresse på den ville skabe en anden, konkurrerende ejer af samme segment. Det er den rettelse, de fleste håndrullede opskrifter får forkert: de adresserer TAP-enheden og broen og undrer sig så over, hvilken af dem partneren faktisk når.

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

Partneren bruger samme form med en anden værtsadresse, og boardene tager adresser i samme interval med computerens broadresse som deres næste hop, hvis de har brug for et. Brug dokumentationsintervaller, indtil planen er aftalt, og reserver intervallet, så det ikke kolliderer med noget, kontoret allerede router. Før du kører noget af det, skal du bekræfte, at medlemsportene ikke bærer en restadresse, ingen DHCP-klient og intet medlemskab af en anden bro, og afstem TAP-enhedens adressering gennem det, der ejer tunnelkonfigurationen, så den ikke gendanner en adresse senere.

Hvorfor én dedikeret port til hver bænk

En dedikeret kablet port er det, der forhindrer forsøget i at blive en ændring for hele kontoret. Administrationsgrænsefladen bærer SSH, standardruten og den ydre VPN-forbindelse, og intet af det hører på en bro, hvis formål er at flytte laboratorierammer.

At tilslutte en administrationsadapter sætter kontorets LAN én videresendelsesbeslutning væk fra et udviklingsboard, og et board, der opfører sig dårligt på lag to, er netop den slags enhed, du ikke vil have på det segment. En Wi-Fi-adapter er værre: at bygge bro over en trådløs grænseflade i infrastrukturtilstand opfører sig ikke som at bygge bro over Ethernet, og fejlen er forvirrende snarere end ren.

Hold laboratorieintervallet ude af ethvert produktions-DHCP-område. Hvis boardene senere får brug for dynamisk adressering, er én autoriseret tildeler med én pulje den eneste ordning, der forbliver forudsigelig; to lokalers almindelige routere, der svarer på samme segment, giver adresser, som ingen kan forklare.

Grænsen, som broen ikke skaber

Broing er ikke routing, og det er heller ikke isolering. Rammer, der krydser broen, kan stadig nå værtens filtreringskroge afhængigt af den installerede bridge-netfilter-vej, så den effektive politik skal undersøges i stedet for at antages. At deaktivere firewallen, fordi en ramme forsvandt, bytter en specifik fejl for en generel.

IP-videresendelse mellem broen og hver administrations- eller uplinkgrænseflade bør forblive slået fra eller være udtrykkeligt nægtet, og det er en separat kontrol fra bromedlemskab. Et board, der vælger computerens laboratorieadresse som sin gateway, tester præcis dette: hvis administrationstrafikken lykkes, var den tilsigtede grænse aldrig der.

To familier mere fortjener en udtrykkelig beslutning. Adresseplanen gør ikke broen IPv4-only, så IPv6 og andre EtherTypes har brug for deres egen plan eller filter. Og en vellykket ping siger intet om, hvorvidt boardets opdagelsesbroadcasts, multicastgrupper eller jumbo-rammer vil passere vejen, fordi det er forskellige trafikklasser med forskellige standarder.

Endelig er transport og fortrolighed to forskellige køb. TAP bærer Ethernet; OpenVPN-tjenesten leverer beskyttelsen omkring det. Et VXLAN-overlay bærer også Ethernet og leverer ingen fortrolighed i sig selv, så at erstatte det ene med det andet ændrer sikkerhedsegenskaberne, selv når topologidiagrammet ser identisk ud.

Vedholdenhed og testene, der beviser den

En kommando, der tastes én gang efter tilslutning, er ikke en konfiguration. Gør broen, portmedlemskabet og den enkelte værtsadresse vedholdende gennem computerens eksisterende netværksadministrator, og bind tilslutningen til TAP-enhedens fremkomst, så en genopkobling ikke efterlader en bro med et forsvundet medlem.

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

Test derefter, hvad boardene faktisk har brug for i begge retninger, genopkobl tunnelen, og genstart én computer efter den godkendte gendannelsesplan. Bekræft tre ting bagefter: administrationsadgang virker stadig uafhængigt, ingen duplikeret laboratorieadresse vises, og ingen uventet produktionsgrænseflade sluttede sig til broen. Den kombination er beviset på, at forsøget blev inden for sin bænk.