Izolēts TAP tilts starp divām platēm caur OpenVPN

Divām izstrādes platēm ir jādala viens Ethernet segments, kamēr to stendi atrodas dažādās ēkās. Tunelis jau pastāv un jau pārsūta Ethernet, tāpēc atlikušais darbs izskatās kā trīs komandas un tāds nav. Ko resursdators dara ar tiltā pārsūtītu kadru, kur pieder paša datora adrese un kādu robežu tilts neveido, ir trīs atsevišķi fakti, un kļūdīšanās otrajā ir ierastais iemesls, kāpēc laboratorija darbojas ar pārtraukumiem un tās pārvaldības piekļuve klusi pasliktinās. Neviens no šiem trim faktiem nav redzams topoloģijas diagrammā.

Tālāk aprakstītais ceļš paredz autentificētu TAP savienojumu starp diviem Linux datoriem, vienu īpašu vadu portu katram stendam un pārvaldības saskarni, kas nav eksperimenta daļa. Secība ir svarīga: vispirms kadri, pēc tam adreses, visbeidzot robeža.

Ko tilts faktiski pārvieto

Tilts ir programmatūrā ieviests komutators. Tas iemācās, kura MAC adrese parādās aiz kura dalībnieka porta, un pārsūta kadrus starp dalībniekiem, neaplūkojot IP maršrutēšanas tabulu. Šajā aprakstā nav apakštīkla, vārtejas vai noklusējuma maršruta, tāpēc IP pārsūtīšanas iespējošana nerada šo savienojumu un tāpēc ping var izdoties, kamēr cits trafiks joprojām neizdodas. Plate var sasniegt savu partneri pilnīgi bez jebkāda konfigurēta noklusējuma maršruta, kas pārsteidz tos, kuri gaida, ka otrais līmenis uzvedīsies kā trešais.

Katrs dators pievieno tiltam vienu vadu portu un TAP ierīci tam pašam tiltam, tāpēc kadrs no plates nonāk vietējā portā, tiek pārsūtīts uz TAP ierīci, šķērso tuneli, nonāk partnera TAP ierīcē un tiek pārsūtīts uz partnera plati. Tunelis ir tāds pats dalībnieka ports kā jebkurš cits, un tilts nezina un neuztraucas, ka aiz tā ir VPN. Tieši šī simetrija padara piemēru viegli saprotamu: katrai pusei ir viens laboratorijas virzienā vērsts ports un viens tuneļa ports, un neviena puse nav īpaša.

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

Vieni un tie paši nosaukumi abos datoros ir vietējie nosaukumi, nevis koplietoti objekti. Starp stendiem ir viens Ethernet ceļš, bez otra kabeļa un bez otra tuneļa, kas noslēgtu cilpu; tilts, kas redz vienu un to pašu MAC ienākam divos portos, labprāt pārsūtīs pa apli.

Adresējiet tiltu, nevis tā dalībnieku portus

Datora identitāte laboratorijas segmentā pieder tilta ierīcei. Dalībnieku porti paliek nenumurēti, jo ports ir pārsūtošs dalībnieks, un adrese uz tā radītu otru, konkurējošu tā paša segmenta īpašnieku. Šis ir labojums, ko lielākā daļa ar roku rakstīto recepšu dara nepareizi: tās adresē TAP ierīci un tiltu un tad brīnās, kuru no tiem partneris faktiski sasniedz.

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

Partneris izmanto to pašu formu ar citu resursdatora adresi, un plates ņem adreses tajā pašā diapazonā, izmantojot datora tilta adresi kā nākamo lēcienu, ja tāda ir vajadzīga. Izmantojiet dokumentācijas diapazonus, līdz plāns ir saskaņots, un rezervējiet diapazonu, lai tas nesadurtos ar neko, ko birojs jau maršrutē. Pirms jebkuras daļas palaišanas pārliecinieties, ka dalībnieku portiem nav atlikušas adreses, DHCP klienta un dalības citā tiltā, un saskaņojiet TAP ierīces adresāciju ar to, kam pieder tuneļa konfigurācija, lai tā vēlāk neatjaunotu adresi.

Kāpēc viens īpašs ports katram stendam

Īpašs vadu ports ir tas, kas neļauj eksperimentam kļūt par visas biroja izmaiņām. Pārvaldības saskarne pārvada SSH, noklusējuma maršrutu un ārējo VPN savienojumu, un nekas no tā nepiekrīt tiltam, kura mērķis ir pārvietot laboratorijas kadrus.

Pārvaldības adaptera pievienošana novieto biroja LAN vienu pārsūtīšanas lēmumu tālu no izstrādes plates, un plate, kas slikti uzvedas otrajā līmenī, ir tieši tāda ierīce, kuru jūs negribat šajā segmentā. Wi-Fi adapteris ir sliktāks: bezvadu saskarnes tiltēšana infrastruktūras režīmā neuzvedas kā Ethernet tiltēšana, un kļūme ir mulsinoša, nevis tīra.

Turiet laboratorijas diapazonu ārpus jebkura ražošanas DHCP apgabala. Ja platēm vēlāk būs vajadzīga dinamiska adresācija, viens pilnvarots sadalītājs ar vienu kopu ir vienīgā kārtība, kas paliek paredzama; divu vietu parastie maršrutētāji, kas atbild tajā pašā segmentā, rada adreses, kuras neviens nevar izskaidrot.

Robeža, ko tilts neveido

Tiltēšana nav maršrutēšana, un tā nav arī izolācija. Kadri, kas šķērso tiltu, joprojām var sasniegt resursdatora filtrēšanas āķus atkarībā no instalētā bridge-netfilter ceļa, tāpēc faktiskā politika ir jāpārbauda, nevis jāpieņem. Ugunsmūra izslēgšana tāpēc, ka pazuda viens kadrs, apmaina konkrētu kļūdu pret vispārīgu.

IP pārsūtīšanai starp tiltu un katru pārvaldības vai uplink saskarni jāpaliek izslēgtai vai skaidri aizliegtai, un tā ir atsevišķa kontrole no dalības tiltā. Plate, kas izvēlas datora laboratorijas adresi kā savu vārteju, pārbauda tieši to: ja pārvaldības tranzīts izdodas, paredzētā robeža nekad nav bijusi.

Vēl divas saimes ir pelnījušas skaidru lēmumu. Adresācijas plāns nepadara tiltu tikai par IPv4, tāpēc IPv6 un citiem EtherType ir vajadzīgs savs plāns vai filtrs. Un veiksmīgs ping neko nepasaka par to, vai plates atklāšanas apraides, multicast grupas vai jumbo kadri šķērsos ceļu, jo tās ir dažādas trafika klases ar dažādām noklusējuma vērtībām.

Visbeidzot, transportēšana un konfidencialitāte ir divi dažādi pirkumi. TAP pārvada Ethernet; OpenVPN pakalpojums nodrošina aizsardzību ap to. VXLAN pārklājums arī pārvada Ethernet un pats par sevi nenodrošina konfidencialitāti, tāpēc viena aizstāšana ar otru maina drošības īpašības pat tad, ja topoloģijas diagramma izskatās identiska.

Noturība un testi, kas to pierāda

Komanda, kas ievadīta vienu reizi pēc savienojuma, nav konfigurācija. Padariet noturīgu tiltu, portu dalību un vienu resursdatora adresi caur esošo datora tīkla pārvaldnieku, un piesaistiet savienojumu TAP ierīces parādīšanās brīdim, lai atkārtots savienojums neatstātu tiltu ar pazudušu dalībnieku.

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

Pēc tam pārbaudiet, kas platēm patiešām vajadzīgs abos virzienos, atkārtoti pievienojiet tuneli un restartējiet vienu datoru saskaņā ar apstiprināto atkopšanas plānu. Pēc tam apstipriniet trīs lietas: pārvaldības piekļuve joprojām darbojas neatkarīgi, neparādās dubulta laboratorijas adrese un nekāda negaidīta ražošanas saskarne nav pievienojusies tiltam. Tieši šī kombinācija ir pierādījums, ka eksperiments palika sava stenda robežās.