Isolert TAP-bro mellom to kort over OpenVPN

To utviklingskort må dele ett Ethernet-segment mens benkene deres står i forskjellige bygninger. Tunnelen finnes allerede og frakter allerede Ethernet, så det gjenstående arbeidet ser ut som tre kommandoer og er det ikke. Hva verten gjør med en broet ramme, hvor datamaskinens egen adresse hører til, og hvilken grense broen ikke skaper er tre separate fakta, og å gjøre den andre feil er den vanlige grunnen til at et laboratorium går ujevnt og administrasjonstilgangen stille forringes. Ingen av disse tre faktaene er synlige i et topologidiagram.

Veien nedenfor forutsetter en autentisert TAP-forbindelse mellom to Linux-maskiner, én dedikert kablet port per benk og et administrasjonsgrensesnitt som ikke er en del av eksperimentet. Rekkefølgen betyr noe: rammer først, adresser deretter, grensen til slutt.

Hva broen faktisk flytter

En bro er en svitsj implementert i programvare. Den lærer hvilken MAC-adresse som vises bak hvilken medlemsport og videresender rammer mellom medlemmer uten å konsultere en IP-rutingstabell. Ingenting i den beskrivelsen involverer et subnett, en gateway eller en standardrute, og derfor skaper aktivering av IP-videresending ikke denne tilkoblingen, og derfor kan en ping lykkes mens annen trafikk fortsatt feiler. Et kort kan nå partneren sin helt uten en konfigurert standardrute, noe som overrasker folk som forventer at lag to skal oppføre seg som lag tre.

Hver maskin bidrar med én kablet port til broen og TAP-enheten til samme bro, slik at en ramme fra et kort kommer inn på den lokale porten, videresendes til TAP-enheten, krysser tunnelen, ankommer partnerens TAP-enhet og videresendes ut til partnerens kort. Tunnelen er en medlemsport som enhver annen, og broen vet ikke eller bryr seg om at det ligger en VPN bak den. Den symmetrien er det som gjør eksempelet lett å resonnere om: hver side har én laboratorierettet port og én tunnelport, og ingen side er spesiell.

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

De identiske navnene på begge maskinene er lokale navn, ikke delte objekter. Det er én Ethernet-vei mellom benkene, uten en andre kabel og uten en andre tunnel som lukker en løkke; en bro som ser den samme MAC-en ankomme på to porter, videresender gjerne i sirkler.

Adresser broen, ikke medlemsportene

Maskinens identitet på laboratoriesegmentet hører til broenheten. Medlemsportene forblir unummererte, fordi en port er et videresendende medlem, og en adresse på den ville skape en andre, konkurrerende eier av samme segment. Dette er rettelsen som de fleste håndskrevne oppskriftene gjør feil: de adresserer TAP-enheten og broen, og lurer deretter på hvilken av 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 bruker samme form med en annen vertsadresse, og kortene tar adresser i samme område med broadressen til maskinen som neste hopp hvis de trenger en. Bruk dokumentasjonsområder til planen er avtalt, og reserver området slik at det ikke kolliderer med noe kontoret allerede ruter. Før du kjører noe av det, bekreft at medlemsportene ikke bærer en restadresse, ingen DHCP-klient og ingen medlemskap i en annen bro, og avstem TAP-enhetens adressering gjennom det som eier tunnelkonfigurasjonen, slik at den ikke gjenoppretter en adresse senere.

Hvorfor én dedikert port per benk

En dedikert kablet port er det som hindrer eksperimentet i å bli en endring for hele kontoret. Administrasjonsgrensesnittet bærer SSH, standardruten og den ytre VPN-forbindelsen, og ingenting av det hører til en bro hvis formål er å flytte laboratorierammer.

Å koble til en administrasjonsadapter setter kontorets LAN én videresendingsbeslutning unna et utviklingskort, og et kort som oppfører seg dårlig på lag to er nettopp den typen enhet du ikke vil ha på det segmentet. En Wi-Fi-adapter er verre: å bro et trådløst grensesnitt i infrastrukturmodus oppfører seg ikke som å bro Ethernet, og feilen er forvirrende snarere enn ren.

Hold laboratorieområdet utenfor ethvert produksjons-DHCP-område. Hvis kortene senere trenger dynamisk adressering, er én autorisert tildeler med én pool den eneste ordningen som forblir forutsigbar; vanlige rutere på to steder som svarer på samme segment, produserer adresser ingen kan forklare.

Grensen broen ikke skaper

Broing er ikke ruting, og det er heller ikke isolasjon. Rammer som krysser broen kan fortsatt nå vertens filtreringskroker, avhengig av installert bridge-netfilter-vei, så den effektive policyen må undersøkes og ikke antas. Å deaktivere brannmuren fordi én ramme forsvant, bytter en spesifikk feil mot en generell.

IP-videresending mellom broen og hvert administrasjons- eller uplinkgrensesnitt bør forbli av eller bli eksplisitt nektet, og det er en kontroll atskilt fra bromedlemskap. Et kort som velger maskinens laboratorieadresse som gateway, tester nettopp dette: hvis administrasjonstrafikken går gjennom, var den tiltenkte grensen aldri der.

To familier til fortjener en eksplisitt beslutning. Adresseplanen gjør ikke broen bare IPv4, så IPv6 og andre EtherTypes trenger sin egen plan eller filter. Og en vellykket ping sier ingenting om hvorvidt kortets oppdagelsesutkringkastinger, multicast-grupper eller jumbo-rammer vil passere veien, fordi det er ulike trafikkklasser med ulike standardverdier.

Til slutt er transport og konfidensialitet to forskjellige kjøp. TAP bærer Ethernet; OpenVPN-tjenesten leverer beskyttelsen rundt det. Et VXLAN-overlegg bærer også Ethernet og leverer ingen konfidensialitet i seg selv, så å erstatte det ene med det andre endrer sikkerhetsegenskapene selv når topologidiagrammet ser identisk ut.

Varighet og testene som beviser den

En kommando som skrives én gang etter tilkobling, er ikke en konfigurasjon. Gjør broen, portmedlemskapet og den ene vertsadressen varige gjennom maskinens eksisterende nettverksbehandler, og bind tilkoblingen til TAP-enhetens fremkomst slik at en gjenoppkobling ikke etterlater en bro med et forsvunnet medlem.

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

Test deretter hva kortene faktisk trenger i begge retninger, koble til tunnelen på nytt og start én maskin på nytt etter den godkjente gjenopprettingsplanen. Bekreft tre ting etterpå: administrasjonstilgang virker fortsatt uavhengig, ingen duplisert laboratorieadresse vises, og ingen uventet produksjonsgrensesnitt har sluttet seg til broen. Den kombinasjonen er beviset på at eksperimentet holdt seg innenfor benken sin.