Geïsoleerde TAP-brug tussen twee boards via OpenVPN

Twee ontwikkelborden moeten één Ethernet-segment delen terwijl hun banken in verschillende gebouwen staan. De tunnel bestaat al en vervoert al Ethernet, dus het resterende werk lijkt op drie commando's en is dat niet. Wat de host met een overbrugd frame doet, waar het eigen adres van de pc hoort en welke grens de brug niet maakt, zijn drie afzonderlijke feiten, en het tweede verkeerd doen is de gebruikelijke reden dat een lab onregelmatig werkt en zijn beheerstoegang stilletjes verslechtert. Geen van die drie feiten is zichtbaar in een topologiediagram.

Het onderstaande pad veronderstelt een geauthenticeerde TAP-verbinding tussen twee Linux-pc's, één speciale bedrade poort per bank en een beheerinterface die geen deel van het experiment is. De volgorde is belangrijk: eerst frames, dan adressen, tot slot de grens.

Wat de brug werkelijk verplaatst

Een brug is een switch die in software is geïmplementeerd. Hij leert welk MAC-adres achter welke lidpoort verschijnt en stuurt frames tussen leden door zonder een IP-routingtabel te raadplegen. Niets in die beschrijving bevat een subnet, een gateway of een standaardroute, daarom levert het inschakelen van IP-doorsturing deze aansluiting niet op en daarom kan een ping slagen terwijl ander verkeer nog steeds faalt. Een bord kan zijn partner bereiken zonder enige geconfigureerde standaardroute, wat mensen verrast die verwachten dat laag twee zich als laag drie gedraagt.

Elke pc levert één bedrade poort aan de brug en het TAP-apparaat aan dezelfde brug, dus een frame van een bord komt binnen op de lokale poort, wordt doorgestuurd naar het TAP-apparaat, kruist de tunnel, komt aan op het TAP-apparaat van de partner en wordt naar het bord van de partner doorgestuurd. De tunnel is een lidpoort als elke andere, en de brug weet niet en geeft er niet om dat er een VPN achter zit. Die symmetrie maakt het voorbeeld makkelijk te beredeneren: elke kant heeft één laboratoriumgerichte poort en één tunnelpoort, en geen kant is bijzonder.

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

De identieke namen op beide pc's zijn lokale namen, geen gedeelde objecten. Er is één Ethernet-pad tussen de banken, zonder tweede kabel en zonder tweede tunnel die een lus sluit; een brug die hetzelfde MAC op twee poorten ziet aankomen, stuurt met plezier in cirkels door.

Adresseer de brug, niet haar lidpoorten

De identiteit van de pc op het laboratoriumsegment hoort bij het brugapparaat. Lidpoorten blijven ongenummerd, want een poort is een doorsturend lid en een adres erop zou een tweede, concurrerende eigenaar van hetzelfde segment maken. Dit is de correctie die de meeste handgemaakte recepten verkeerd doen: ze adresseren het TAP-apparaat en de brug, en vragen zich dan af welke van de twee de partner werkelijk bereikt.

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

De partner gebruikt dezelfde vorm met een ander hostadres, en de borden nemen adressen in dezelfde reeks met het brugadres van de pc als hun volgende hop als ze er een nodig hebben. Gebruik documentatiereeksen tot het plan is overeengekomen, en reserveer de reeks zodat die niet botst met iets wat het kantoor al routeert. Bevestig voordat u iets uitvoert dat de lidpoorten geen restadres, geen DHCP-client en geen lidmaatschap van een andere brug dragen, en stem de adressering van het TAP-apparaat af via wat de tunnelconfiguratie bezit, zodat het later geen adres herstelt.

Waarom één speciale poort per bank

Een speciale bedrade poort is wat voorkomt dat het experiment een kantoorbrede wijziging wordt. De beheerinterface draagt SSH, de standaardroute en de buitenste VPN-verbinding, en niets daarvan hoort op een brug waarvan het doel is laboratoriumframes te verplaatsen.

Het aansluiten van een beheeradapter zet het kantoor-LAN één doorstuurdecisie verwijderd van een ontwikkelbord, en een bord dat zich op laag twee slecht gedraagt is precies het soort apparaat dat u niet op dat segment wilt. Een Wi-Fi-adapter is erger: het overbruggen van een draadloze interface in infrastructuurmodus gedraagt zich niet als het overbruggen van Ethernet, en de fout is verwarrend in plaats van schoon.

Houd de laboratoriumreeks buiten elk productie-DHCP-bereik. Als de borden later dynamische adressering nodig hebben, is één geautoriseerde toewijzer met één pool de enige regeling die voorspelbaar blijft; gewone routers van twee locaties die op hetzelfde segment antwoorden, produceren adressen die niemand kan verklaren.

De grens die de brug niet maakt

Bruggen is geen routing, en het is ook geen isolatie. Frames die de brug passeren kunnen nog steeds de filterhaken van de host bereiken, afhankelijk van het geïnstalleerde bridge-netfilterpad, dus het effectieve beleid moet worden geïnspecteerd en niet aangenomen. De firewall uitschakelen omdat één frame zoekraakte, ruilt een specifieke bug voor een algemene.

IP-doorsturing tussen de brug en elke beheer- of uplinkinterface moet uit blijven of expliciet worden geweigerd, en dat is een aparte controle van lidmaatschap van de brug. Een bord dat het laboratoriumadres van de pc als gateway kiest, test precies dit: als het beheerverkeer doorkomt, was de bedoelde grens er nooit.

Nog twee families verdienen een expliciete beslissing. Het adresplan maakt de brug niet alleen-IPv4, dus IPv6 en andere EtherTypes hebben hun eigen plan of filter nodig. En een geslaagde ping zegt niets over of de ontdekkingsbroadcasts, multicastgroepen of jumbo-frames van het bord het pad zullen passeren, want dat zijn verschillende verkeersklassen met verschillende standaardwaarden.

Ten slotte zijn transport en vertrouwelijkheid twee verschillende aankopen. TAP draagt Ethernet; de OpenVPN-dienst levert de bescherming eromheen. Een VXLAN-overlay draagt ook Ethernet en levert op zichzelf geen vertrouwelijkheid, dus het ene door het andere vervangen verandert de beveiligingseigenschappen zelfs wanneer het topologiediagram identiek lijkt.

Duurzaamheid en de tests die het bewijzen

Een commando dat één keer na het verbinden wordt getypt is geen configuratie. Maak de brug, het poortlidmaatschap en het enkele hostadres duurzaam via de bestaande netwerkbeheerder van de pc, en koppel de aansluiting aan het verschijnen van het TAP-apparaat zodat een herverbinding geen brug met een verdwenen lid achterlaat.

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

Test daarna wat de borden in beide richtingen echt nodig hebben, verbind de tunnel opnieuw en herstart één pc volgens het goedgekeurde herstelplan. Bevestig daarna drie dingen: beheerstoegang werkt nog steeds onafhankelijk, er verschijnt geen dubbel laboratoriumadres en geen onverwachte productie-interface is lid geworden van de brug. Die combinatie is het bewijs dat het experiment binnen zijn bank bleef.