Isolert TAP-bru mellom to kort over OpenVPN

To utviklingskort må dele eitt Ethernet-segment medan benkane deira står i ulike bygg. Tunnelen finst allereie og fraktar allereie Ethernet, så det gjenverande arbeidet ser ut som tre kommandoar og er det ikkje. Kva verten gjer med ei brua ramme, kvar datamaskina si eiga adresse høyrer til, og kva grense brua ikkje skapar er tre separate fakta, og å gjere den andre feil er den vanlege grunnen til at eit laboratorium går ujamt og administrasjonstilgangen stille blir dårlegare. Ingen av desse tre faktaa er synlege i eit topologidiagram.

Vegen nedanfor føreset ei autentisert TAP-tilkopling mellom to Linux-maskinar, éin dedikert kabelport per benk og eit administrasjonsgrensesnitt som ikkje er ein del av eksperimentet. Rekkjefølgja har mykje å seie: rammer fyrst, adresser deretter, grensa til slutt.

Kva brua faktisk flyttar

Ei bru er ein svitsj implementert i programvare. Ho lærer kva MAC-adresse som viser seg bak kva medlemsport og sender rammer vidare mellom medlemmar utan å rådspørje ein IP-rutartabell. Ingenting i den skildringa involverer eit subnett, ein gateway eller ei standardrute, og difor skapar aktivering av IP-vidaresending ikkje denne tilkoplinga, og difor kan ein ping lukkast medan annan trafikk framleis feilar. Eit kort kan nå partnaren sin heilt utan ei konfigurert standardrute, noko som overraskar folk som ventar at lag to skal oppføre seg som lag tre.

Kvar maskin bidreg med éin kabelport til brua og TAP-eininga til same bru, slik at ei ramme frå eit kort kjem inn på den lokale porten, blir send vidare til TAP-eininga, kryssar tunnelen, kjem fram til TAP-eininga til partnaren og blir send ut til kortet hans. Tunnelen er ein medlemsport som kvar annan, og brua veit ikkje eller bryr seg om at det ligg ein VPN bak han. Den symmetrien er det som gjer dømet lett å resonnere om: kvar side har éin laboratorieretta port og éin tunnelport, og inga side er spesiell.

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

Dei identiske namna på begge maskinane er lokale namn, ikkje delte objekt. Det er éin Ethernet-veg mellom benkane, utan ein andre kabel og utan ein andre tunnel som lukkar ei løkke; ei bru som ser den same MAC-en kome på to portar, sender gjerne vidare i sirklar.

Adresser brua, ikkje medlemsportane

Identiteten til maskina på laboratoriesegmentet høyrer til brueininga. Medlemsportane blir ståande unummererte, fordi ein port er eit vidaresendande medlem, og ei adresse på han ville skape ein andre, konkurrerande eigar av same segment. Dette er rettinga som dei fleste handskrivne oppskriftene gjer feil: dei adresserer TAP-eininga og brua, og lurer deretter på kva av dei partnaren 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

Partnaren brukar same form med ei anna vertsadresse, og kortet tek adresser i same område med broadressa til maskina som neste hopp om det treng ein. Bruk dokumentasjonsområde til planen er avtalt, og reserver området slik at det ikkje kolliderer med noko kontoret allereie ruter. Før du køyrer noko av det, stadfest at medlemsportane ikkje ber ei restadresse, ingen DHCP-klient og ikkje medlemskap i ei anna bru, og avstem TAP-eininga si adressering gjennom det som eig tunnelkonfigurasjonen, slik at ho ikkje gjenopprettar ei adresse seinare.

Kvifor éin dedikert port per benk

Ein dedikert kabelport er det som hindrar eksperimentet i å bli ei endring for heile kontoret. Administrasjonsgrensesnittet ber SSH, standardruta og den ytre VPN-tilkoplinga, og ingenting av det høyrer til ei bru der føremålet er å flytte laboratorierammer.

Å kople til ein administrasjonsadapter set kontoret sitt LAN éin vidaresendingsavgjerd unna eit utviklingskort, og eit kort som oppfører seg dårleg på lag to er nettopp den typen eining du ikkje vil ha på det segmentet. Ein Wi-Fi-adapter er verre: å bru eit trådlaust grensesnitt i infrastrukturmodus oppfører seg ikkje som å bru Ethernet, og feilen er forvirrande snarare enn rein.

Hald laboratorieområdet utanfor eitkvart produksjons-DHCP-område. Om kortet seinare treng dynamisk adressering, er éin autorisert tildelar med éin pool den einaste ordninga som held seg føreseieleg; vanlege rutarar på to stader som svarar på same segment, produserer adresser ingen kan forklare.

Grensa brua ikkje skapar

Bruing er ikkje ruting, og det er heller ikkje isolasjon. Rammer som kryssar brua kan framleis nå filtreringskrokane til verten, avhengig av installert bridge-netfilter-veg, så den effektive politikken må granskast og ikkje antakast. Å slå av brannmuren fordi éi ramme forsvann, byter ein spesifikk feil mot ein generell.

IP-vidaresending mellom brua og kvart administrasjons- eller uplinkgrensesnitt bør halde seg av eller bli eksplisitt nekta, og det er ein kontroll atskild frå brumedlemskap. Eit kort som vel laboratorieadressa til maskina som gateway, testar nettopp dette: om administrasjonstrafikken går gjennom, var den tiltenkte grensa aldri der.

To familiar til fortener ei eksplisitt avgjerd. Adresseplanen gjer ikkje brua berre IPv4, så IPv6 og andre EtherTypes treng sin eigen plan eller filter. Og ein vellukka ping seier ingenting om kortet sine oppdagingskringkastingar, multicast-grupper eller jumbo-rammer vil passere vegen, fordi det er ulike trafikkklasser med ulike standardverdiar.

Til slutt er transport og konfidensialitet to ulike kjøp. TAP ber Ethernet; OpenVPN-tenesta leverer vernet rundt det. Eit VXLAN-overlegg ber også Ethernet og leverer ingen konfidensialitet i seg sjølv, så å byte ut det eine med det andre endrar tryggleikseigenskapane sjølv når topologidiagrammet ser identisk ut.

Varigheit og testane som provar ho

Ein kommando som blir skriven éin gong etter tilkopling, er ikkje ein konfigurasjon. Gjer brua, portmedlemskapen og den eine vertsadressa varige gjennom den eksisterande nettverkshandsamaren til maskina, og bind tilkoplinga til framkomsten av TAP-eininga slik at ei gjenoppkopling ikkje etterlèt ei bru med eit forsvunne medlem.

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

Test deretter kva kortet faktisk treng i begge retningar, kople til tunnelen på nytt og start éi maskin på nytt etter den godkjende gjenopprettingsplanen. Stadfest tre ting etterpå: administrasjonstilgangen verkar framleis uavhengig, inga duplisert laboratorieadresse viser seg, og ingen uventa produksjonsgrensesnitt har slutta seg til brua. Den kombinasjonen er provet på at eksperimentet heldt seg innanfor benken sin.