Isolerad TAP-brygga mellan två kort över OpenVPN

Två utvecklingskort måste dela ett Ethernet-segment medan deras bänkar står i olika byggnader. Tunneln finns redan och transporterar redan Ethernet, så det återstående arbetet ser ut som tre kommandon och är det inte. Vad värden gör med en bryggad ram, var datorns egen adress hör hemma och vilken gräns bryggan inte skapar är tre separata fakta, och att göra det andra felet är det vanliga skälet till att ett labb fungerar ojämnt och dess administrationsåtkomst tyst försämras. Ingen av dessa tre fakta syns i ett topologidiagram.

Vägen nedan förutsätter en autentiserad TAP-anslutning mellan två Linux-datorer, en dedikerad kabelport per bänk och ett administrationsgränssnitt som inte är en del av experimentet. Ordningen spelar roll: ramar först, adresser sedan, gränsen sist.

Vad bryggan faktiskt flyttar

En brygga är en switch implementerad i programvara. Den lär sig vilken MAC-adress som dyker upp bakom vilken medlemsport och vidarebefordrar ramar mellan medlemmar utan att konsultera en IP-routingtabell. Inget i den beskrivningen innefattar ett subnät, en gateway eller en standardrutt, vilket är varför aktivering av IP-vidarebefordran inte skapar denna anslutning och varför en ping kan lyckas medan annan trafik fortfarande misslyckas. Ett kort kan nå sin partner helt utan en konfigurerad standardrutt, vilket förvånar dem som förväntar sig att lager två ska bete sig som lager tre.

Varje dator bidrar med en kabelport till bryggan och TAP-enheten till samma brygga, så en ram från ett kort kommer in på den lokala porten, vidarebefordras till TAP-enheten, korsar tunneln, anländer till partnerns TAP-enhet och vidarebefordras ut till partnerns kort. Tunneln är en medlemsport som vilken annan som helst, och bryggan vet inte eller bryr sig om att det ligger en VPN bakom den. Den symmetrin är det som gör exemplet lätt att resonera om: varje sida har en labbriktad port och en tunnelport, och ingen sida är speciell.

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

De identiska namnen på båda datorerna är lokala namn, inte delade objekt. Det finns en Ethernet-väg mellan bänkarna, utan en andra kabel och utan en andra tunnel som sluter en slinga; en brygga som ser samma MAC anlända på två portar vidarebefordrar gärna i cirklar.

Adressera bryggan, inte dess medlemsportar

Datorns identitet på laboratorisegmentet hör till bryggans enhet. Medlemsportarna förblir onumrerade, eftersom en port är en vidarebefordrande medlem och en adress på den skulle skapa en andra, konkurrerande ägare av samma segment. Detta är rättelsen som de flesta handskrivna recept gör fel: de adresserar TAP-enheten och bryggan och undrar sedan vilken av dem partnern faktiskt 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

Partnern använder samma form med en annan värdadress, och korten tar adresser i samma intervall med datorns bryggadress som nästa hopp om de behöver ett. Använd dokumentationsintervall tills planen är överenskommen, och reservera intervallet så att det inte kolliderar med något som kontoret redan routar. Innan du kör något av det, bekräfta att medlemsportarna inte bär någon restadress, ingen DHCP-klient och inget medlemskap i en annan brygga, och stäm av TAP-enhetens adressering genom det som äger tunnelkonfigurationen så att den inte återställer en adress senare.

Varför en dedikerad port per bänk

En dedikerad kabelport är det som hindrar experimentet från att bli en ändring för hela kontoret. Administrationsgränssnittet bär SSH, standardrutten och den yttre VPN-anslutningen, och inget av det hör till en brygga vars syfte är att flytta laboratorieramar.

Att ansluta en administrationsadapter sätter kontorets LAN en vidarebefordringsbeslut bort från ett utvecklingskort, och ett kort som beter sig illa på lager två är precis den typ av enhet du inte vill ha på det segmentet. En Wi-Fi-adapter är värre: att brygga ett trådlöst gränssnitt i infrastrukturläge beter sig inte som att brygga Ethernet, och felet är förvirrande snarare än rent.

Håll laboratorieintervallet utanför alla produktions-DHCP-områden. Om korten senare behöver dynamisk adressering är en auktoriserad tilldelare med en pool det enda arrangemanget som förblir förutsägbart; vanliga routrar på två platser som svarar på samma segment producerar adresser som ingen kan förklara.

Gränsen som bryggan inte skapar

Bryggning är inte routing, och det är inte heller isolering. Ramar som korsar bryggan kan fortfarande nå värdens filtreringskrokar, beroende på den installerade bridge-netfilter-vägen, så den effektiva policyn måste inspekteras och inte antas. Att stänga av brandväggen för att en ram försvann byter ett specifikt fel mot ett allmänt.

IP-vidarebefordran mellan bryggan och varje administrations- eller uplinkgränssnitt bör förbli avstängd eller uttryckligen nekas, och det är en kontroll skild från bryggmedlemskap. Ett kort som väljer datorns laboratorieadress som sin gateway testar precis detta: om administrationstrafiken går igenom fanns den avsedda gränsen aldrig.

Ytterligare två familjer förtjänar ett uttryckligt beslut. Adressplanen gör inte bryggan enbart IPv4, så IPv6 och andra EtherTypes behöver sin egen plan eller filter. Och en lyckad ping säger ingenting om huruvida kortets upptäcktsutsändningar, multicastgrupper eller jumbo-ramar kommer att passera vägen, eftersom det är olika trafikklasser med olika standardvärden.

Slutligen är transport och konfidentialitet två olika köp. TAP bär Ethernet; OpenVPN-tjänsten levererar skyddet runt omkring. Ett VXLAN-overlay bär också Ethernet och levererar ingen konfidentialitet i sig självt, så att ersätta det ena med det andra ändrar säkerhetsegenskaperna även när topologidiagrammet ser identiskt ut.

Varaktighet och testerna som bevisar den

Ett kommando som skrivs en gång efter anslutning är inte en konfiguration. Gör bryggan, portmedlemskapet och den enda värdadressen varaktiga genom datorns befintliga nätverkshanterare, och bind anslutningen till TAP-enhetens framträdande så att en återanslutning inte lämnar en brygga med en försvunnen medlem.

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

Testa sedan vad korten verkligen behöver i båda riktningarna, återanslut tunneln och starta om en dator enligt den godkända återställningsplanen. Bekräfta tre saker efteråt: administrationsåtkomsten fungerar fortfarande oberoende, ingen duplicerad laboratorieadress visas och inget oväntat produktionsgränssnitt har anslutit sig till bryggan. Den kombinationen är beviset på att experimentet stannade inom sin bänk.