Geïsoleerde TAP-brug tussen twee borde oor OpenVPN

Twee ontwikkelingsborde moet een Ethernet-segment deel terwyl hul werkbanke in verskillende geboue staan. Die tonnel bestaan reeds en vervoer reeds Ethernet, so die oorblywende werk lyk soos drie opdragte en is dit nie. Wat die gasheer met ’n oorbrugde raam doen, waar die rekenaar se eie adres hoort, en watter grens die brug nie skep nie, is drie afsonderlike feite, en om die tweede een verkeerd te kry, is die gewone rede waarom ’n laboratorium ongereeld werk en sy bestuurstoegang stilweg agteruitgaan. Nie een van daardie drie feite is in ’n topologie-diagram sigbaar nie.

Die pad hieronder veronderstel ’n geauthentiseerde TAP-verbinding tussen twee Linux-rekenaars, een toegewyde bedrade poort per werkbank, en ’n bestuurskoppelvlak wat nie deel van die eksperiment is nie. Die volgorde maak saak: rame eerste, adresse tweede, grens laaste.

Wat die brug werklik vervoer

’n Brug is ’n skakelaar wat in sagteware geïmplementeer is. Dit leer watter MAC-adres agter watter lidpoort verskyn en stuur rame tussen lede deur sonder om ’n IP-roetingtabel te raadpleeg. Niks in daardie beskrywing behels ’n subnet, ’n gateway of ’n verstekroete nie, en daarom lewer die aktiveer van IP-aansturing nie hierdie koppeling nie en kan ’n ping slaag terwyl ander verkeer steeds misluk. ’n Bord kan sy eweknie bereik sonder enige verstekroete wat opgestel is, wat mense verras wat verwag dat laag twee soos laag drie moet optree.

Elke rekenaar dra een bedrade poort by die brug by en die TAP-toestel by dieselfde brug, so ’n raam van ’n bord kom by die plaaslike poort in, word na die TAP-toestel deurgestuur, kruis die tonnel, kom op die eweknie se TAP-toestel aan en word na die eweknie se bord uitgestuur. Die tonnel is ’n lidpoort soos enige ander, en die brug weet nie of gee nie om dat ’n VPN daar agter sit nie. Daardie simmetrie is wat die voorbeeld maklik maak om te beredeneer: elke kant het een laboratoriumgerigte poort en een tonnelpoort, en geen kant is spesiaal nie.

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

Die identiese name op albei rekenaars is plaaslike name, nie gedeelde objekte nie. Daar is een Ethernet-pad tussen die werkbanke, met geen tweede kabel en geen tweede tonnel wat ’n lus sluit nie; ’n brug wat dieselfde MAC op twee poorte sien aankom, sal met plesier in sirkels deurstuur.

Adresseer die brug, nie sy lidpoorte nie

Die rekenaar se identiteit op die laboratoriumsegment hoort by die brugtoestel. Lidpoorte bly ongenommer, want ’n poort is ’n deurstuur-lid en ’n adres daarop sou ’n tweede, mededingende eienaar van dieselfde segment skep. Dit is die regstelling wat die meeste selfgeboude resepte verkeerd kry: hulle adresseer die TAP-toestel en die brug, en wonder dan watter een die eweknie werklik bereik.

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

Die eweknie gebruik dieselfde vorm met ’n ander gasheeradres, en die borde neem adresse in dieselfde reeks met die rekenaar se brugadres as hul volgende sprong as hulle een nodig het. Gebruik dokumentasiereekse tot die plan ooreengekom is, en reserveer die reeks sodat dit nie bots met enigiets wat die kantoor reeds roeteer nie. Voordat jy enigiets daarvan uitvoer, bevestig dat die lidpoorte geen oorblywende adres, geen DHCP-kliënt en geen lidmaatskap in ’n ander brug het nie, en versoen die TAP-toestel se adressering deur wat die tonnelkonfigurasie ook al besit, sodat dit nie later ’n adres herstel nie.

Waarom een toegewyde poort per werkbank

’n Toegewyde bedrade poort is wat keer dat die eksperiment ’n kantoorwye verandering word. Die bestuurskoppelvlak dra SSH, die verstekroete en die buitenste VPN-verbinding, en niks daarvan hoort op ’n brug wie se doel dit is om laboratoriumrame te vervoer nie.

Om ’n bestuursadapter aan te sluit plaas die kantoor-LAN een deurstuurbesluit weg van ’n ontwikkelingsbord, en ’n bord wat op laag twee wangedra is presies die soort toestel wat jy nie op daardie segment wil hê nie. ’n Wi-Fi-adapter is erger: om ’n draadlose koppelvlak in infrastruktuurmodus te oorbrug, gedra dit nie soos die oorbrug van Ethernet nie, en die mislukking is verwarrend eerder as skoon.

Hou die laboratoriumreeks uit enige produksie-DHCP-bestek. As die borde later dinamiese adressering nodig het, is een gemagtigde toewyser met een poel die enigste reëling wat voorspelbaar bly; twee terreine se gewone routers wat op dieselfde segment antwoord, lewer adresse wat niemand kan verduidelik nie.

Die grens wat die brug nie skep nie

Oorbrug is nie roetering nie, en dit is ook nie isolasie nie. Rame wat die brug kruis, kan steeds die gasheer se filterhake bereik, afhangende van die geïnstalleerde brug-netfilter-pad, so die effektiewe beleid moet ondersoek word eerder as aangeneem. Om die firewall te deaktiveer omdat een raam verdwyn het, ruil ’n spesifieke fout vir ’n algemene een.

IP-deursturing tussen die brug en elke bestuurs- of opkoppelkoppelvlak moet af bly of eksplisiet geweier word, en dit is ’n aparte beheer van bruglidmaatskap. ’n Bord wat die rekenaar se laboratoriumadres as sy gateway kies, toets presies dit: as bestuursdeurgang slaag, was die grens wat jy bedoel het nooit daar nie.

Twee verdere families verdien ’n eksplisiete besluit. Die adresplan maak nie die brug slegs-IPv4 nie, so IPv6 en ander EtherTypes het hul eie plan of filter nodig. En ’n suksesvolle ping sê niks oor of die bord se ontdekkings-uitsendings, multicast-groepe of jumbo-rame die pad sal kruis nie, want dit is verskillende verkeersklasse met verskillende verstekke.

Laastens, vervoer en vertroulikheid is verskillende aankope. TAP vervoer Ethernet; die OpenVPN-diens lewer die beskerming daaromheen. ’n VXLAN-oorleg vervoer ook Ethernet en lewer op sigself geen vertroulikheid nie, so om een vir die ander te vervang verander die sekuriteitseienskappe selfs wanneer die topologie-diagram identies lyk.

Volharding en die toetse wat dit bewys

’n Opdrag wat een keer na die koppeling getik word, is nie ’n konfigurasie nie. Volhard die brug, die poortlidmaatskap en die enkele gasheeradres deur die rekenaar se bestaande netwerkbestuurder, en bind die koppeling aan die TAP-toestel se verskyning sodat ’n herkoppeling nie ’n brug met ’n verdwenste lid laat nie.

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

Toets dan wat die borde werklik in beide rigtings nodig het, koppel die tonnel weer, en herbegin een rekenaar volgens die goedgekeurde herstelplan. Bevestig daarna drie dinge: bestuurstoegang werk steeds onafhanklik, geen duplikaat-laboratoriumadres verskyn nie, en geen onverwagte produksiekoppelvlak het by die brug aangesluit nie. Daardie kombinasie is die bewys dat die eksperiment binne sy werkbank gebly het.