Elszigetelt TAP-híd két board között OpenVPN-en át

Két fejlesztői boardnak egy Ethernet-szegmenst kell megosztania, miközben a padjaik különböző épületekben vannak. Az alagút már létezik és már szállít Ethernetet, így a hátralévő munka három parancsnak látszik, és nem az. Hogy a gazdagép mit tesz egy áthidalt kerettel, hová tartozik a számítógép saját címe, és milyen határt nem hoz létre a híd, három külön tény, és a második elrontása a szokásos oka annak, hogy egy laboratórium szakaszosan működik, és a felügyeleti hozzáférése csendben romlik. E három tény egyike sem látható egy topológiai ábrán.

Az alábbi útvonal hitelesített TAP-kapcsolatot feltételez két Linux-számítógép között, padonként egy dedikált vezetékes portot, és egy felügyeleti interfészt, amely nem része a kísérletnek. A sorrend számít: először a keretek, aztán a címek, végül a határ.

Mit mozgat valójában a híd

A híd szoftverben megvalósított kapcsoló. Megtanulja, melyik MAC-cím melyik tagport mögött jelenik meg, és IP-útválasztási táblázat nélkül továbbítja a kereteket a tagok között. Ebben a leírásban nincs alhálózat, átjáró vagy alapértelmezett útvonal, ezért az IP-továbbítás engedélyezése nem hozza létre ezt a csatlakozást, és ezért sikerülhet egy ping, miközben más forgalom továbbra is elakad. Egy board alapértelmezett útvonal nélkül is elérheti a partnerét, ami meglepi azokat, akik azt várják, hogy a második réteg úgy viselkedjen, mint a harmadik.

Minden számítógép egy vezetékes portot ad a hídnak és a TAP-eszközt ugyanannak a hídnak, így a board kerete belép a helyi portba, továbbítódik a TAP-eszközre, átkel az alagúton, megérkezik a partner TAP-eszközére, és továbbítódik a partner boardjára. Az alagút tagport, mint bármely másik, és a híd nem tudja és nem érdekli, hogy mögötte VPN van. Ez a szimmetria teszi a példát könnyen átgondolhatóvá: mindkét oldalon egy labor felé néző port és egy alagútport van, és egyik oldal sem különleges.

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

A két számítógépen azonos nevek helyi nevek, nem megosztott objektumok. A padok között egyetlen Ethernet-út van, második kábel és hurkot záró második alagút nélkül; a híd, amely ugyanazt a MAC-ot két porton látja megérkezni, vidáman továbbít körökben.

A hidat címezze, ne a tagportjait

A számítógép identitása a laboratóriumi szegmensen a hídeszközhöz tartozik. A tagportok számozatlanok maradnak, mert a port továbbító tag, és a rajta lévő cím egy második, versengő tulajdonost hozna létre ugyanazon a szegmensen. Ez az a javítás, amelyet a legtöbb kézzel írt recept elront: a TAP-eszközt és a hidat is címzik, majd azon tűnődnek, melyiket éri el valójában a partner.

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

A partner ugyanazt a formát használja más gazdagép-címmel, és a boardok ugyanabban a tartományban vesznek fel címeket, a számítógép híd-címét használva következő ugrásként, ha szükségük van rá. Használjon dokumentációs tartományokat, amíg a terv meg nem egyezik, és foglalja le a tartományt, hogy ne ütközzön semmivel, amit az iroda már irányít. Mielőtt bármelyiket futtatná, erősítse meg, hogy a tagportokon nincs maradék cím, DHCP-kliens és másik hídban való tagság, és hangolja össze a TAP-eszköz címzését azzal, ami az alagút konfigurációját birtokolja, hogy később ne állítson vissza egy címet.

Miért egy dedikált port padonként

A dedikált vezetékes port az, ami megakadályozza, hogy a kísérlet iroda-szintű változássá váljon. A felügyeleti interfész viszi az SSH-t, az alapértelmezett útvonalat és a külső VPN-kapcsolatot, és ezek egyike sem tartozik arra a hídra, amelynek célja laboratóriumi keretek mozgatása.

Egy felügyeleti adapter csatlakoztatása az iroda LAN-ját egy továbbítási döntésnyire helyezi egy fejlesztői boardtól, és a második rétegen rosszul viselkedő board pontosan az az eszköz, amelyet nem akar azon a szegmensen. A Wi-Fi-adapter rosszabb: egy vezeték nélküli interfész áthidalása infrastruktúra módban nem úgy viselkedik, mint az Ethernet áthidalása, és a hiba zavaros, nem tiszta.

Tartsa a laboratóriumi tartományt minden termelési DHCP-tartományon kívül. Ha a boardoknak később dinamikus címzésre van szükségük, egyetlen feljogosított kiosztó egyetlen medencével az egyetlen elrendezés, amely kiszámítható marad; két telephely közönséges routerei, amelyek ugyanazon a szegmensen válaszolnak, olyan címeket állítanak elő, amelyeket senki sem tud megmagyarázni.

A határ, amelyet a híd nem hoz létre

Az áthidalás nem útválasztás, és nem is elszigetelés. A hidat átlépő keretek még elérhetik a gazdagép szűrőhorgait, a telepített bridge-netfilter útvonaltól függően, ezért a tényleges szabályzatot meg kell vizsgálni, nem feltételezni. A tűzfal kikapcsolása egy elveszett keret miatt egy konkrét hibát cserél egy általánosra.

A híd és minden felügyeleti vagy uplink interfész közötti IP-továbbítást ki kell kapcsolva tartani vagy kifejezetten megtagadni, és ez a híd-tagságtól különálló vezérlés. Az a board, amely a számítógép laborcímét választja átjárójaként, pontosan ezt teszteli: ha a felügyeleti átjárás sikerül, a szándékolt határ soha nem volt ott.

Két további család érdemel kifejezett döntést. A címterv nem teszi a hidat csak IPv4-essé, ezért az IPv6-nak és más EtherType-oknak saját tervre vagy szűrőre van szükségük. És egy sikeres ping semmit sem mond arról, hogy a board felderítési sugárzásai, multicast csoportjai vagy jumbo keretei átjutnak-e az útvonalon, mert ezek különböző forgalmi osztályok különböző alapértékekkel.

Végül, a szállítás és a bizalmasság két különböző vásárlás. A TAP Ethernetet szállít; az OpenVPN szolgáltatás biztosítja a körülötte lévő védelmet. A VXLAN overlay is szállít Ethernetet, és önmagában nem biztosít bizalmasságot, így az egyik helyettesítése a másikkal megváltoztatja a biztonsági tulajdonságokat akkor is, amikor a topológiai ábra azonosnak látszik.

Tartósság és az azt bizonyító tesztek

A csatlakozás után egyszer beírt parancs nem konfiguráció. Tegye tartóssá a hidat, a porttagságot és az egyetlen gazdagép-címet a számítógép meglévő hálózatkezelőjén keresztül, és kösse a csatlakozást a TAP-eszköz megjelenéséhez, hogy egy újracsatlakozás ne hagyjon hátra hidat eltűnt taggal.

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

Ezután tesztelje, mire van valóban szükségük a boardoknak mindkét irányban, csatlakoztassa újra az alagutat, és indítson újra egy számítógépet a jóváhagyott helyreállítási terv szerint. Ezután erősítsen meg három dolgot: a felügyeleti hozzáférés továbbra is önállóan működik, nem jelenik meg duplikált laborcím, és semmilyen váratlan termelési interfész nem csatlakozott a hídhoz. Ez a kombináció a bizonyíték arra, hogy a kísérlet a padján belül maradt.