Isolated na TAP bridge sa pagitan ng dalawang board sa pamamagitan ng OpenVPN

Dalawang development board ang kailangang maghati sa isang Ethernet segment habang ang kanilang mga bangko ay nasa magkaibang gusali. Umiiral na ang tunnel at nagdadala na ng Ethernet, kaya ang natitirang trabaho ay mukhang tatlong command at hindi ito. Ang ginagawa ng host sa isang frame na na-bridge, kung saan kabilang ang sariling address ng computer, at kung anong hangganan ang hindi nililikha ng tulay ay tatlong magkaibang katotohanan, at ang pagkakamali sa pangalawa ang karaniwang dahilan kung bakit pana-panahong gumagana ang laboratoryo at tahimik na bumababa ang access sa pamamahala nito. Wala sa tatlong katotohanang ito ang nakikita sa isang diagram ng topolohiya.

Ipinapalagay ng landas sa ibaba ang isang authenticated na TAP connection sa pagitan ng dalawang Linux computer, isang dedikadong wired port sa bawat bangko, at isang management interface na hindi bahagi ng eksperimento. Mahalaga ang pagkakasunod-sunod: una ang mga frame, pagkatapos ang mga address, sa huli ang hangganan.

Ano ang aktwal na ginagalaw ng tulay

Ang tulay ay isang switch na ipinatupad sa software. Natututuhan nito kung aling MAC address ang lumilitaw sa likod ng aling miyembrong port at nagpapasa ng mga frame sa pagitan ng mga miyembro nang hindi kumukonsulta sa isang IP routing table. Wala sa paglalarawang iyon ang may subnet, gateway, o default na ruta, kaya ang pagpapagana ng IP forwarding ay hindi lumilikha ng koneksyong ito at kaya ang ping ay maaaring magtagumpay habang ang ibang trapiko ay nabigo pa rin. Maaaring maabot ng board ang kapareha nito nang walang anumang naka-configure na default na ruta, na nakakagulat sa mga umaasang ang layer two ay kikilos tulad ng layer three.

Ang bawat computer ay nag-aambag ng isang wired port sa tulay at ang TAP device sa parehong tulay, kaya ang isang frame mula sa board ay pumapasok sa lokal na port, ipinapasa sa TAP device, tumatawid sa tunnel, dumarating sa TAP device ng kapareha, at ipinapasa sa board ng kapareha. Ang tunnel ay isang miyembrong port tulad ng iba pa, at hindi alam o pinapahalagahan ng tulay na may VPN sa likod nito. Ang simetryang iyon ang nagpapadali sa halimbawa: may isang port na nakaharap sa laboratoryo at isang tunnel port ang bawat panig, at walang panig na espesyal.

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

Ang magkatulad na pangalan sa dalawang computer ay lokal na pangalan, hindi magkabahaging bagay. May isang Ethernet na landas sa pagitan ng mga bangko, walang pangalawang cable at walang pangalawang tunnel na nagsasara ng loop; ang tulay na nakakakita ng parehong MAC na dumarating sa dalawang port ay masayang magpapasa nang paikot.

Bigyan ng address ang tulay, hindi ang mga miyembrong port nito

Ang pagkakakilanlan ng computer sa segment ng laboratoryo ay kabilang sa device ng tulay. Ang mga miyembrong port ay nananatiling walang numero, dahil ang port ay isang miyembrong nagpapasa at ang isang address dito ay lilikha ng pangalawa at karibal na may-ari ng parehong segment. Ito ang pagwawastong mali ng karamihan sa mga recipe na ginawa sa kamay: binibigyan nila ng address ang TAP device at ang tulay, at pagkatapos ay nagtatanong kung alin sa dalawa ang aktwal na naaabot ng kapareha.

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

Gumagamit ang kapareha ng parehong hugis na may ibang host address, at ang mga board ay kumukuha ng mga address sa parehong saklaw gamit ang address ng tulay ng computer bilang susunod na hop kung kailangan nila. Gumamit ng mga documentation range hanggang magkasundo sa plano, at ireserba ang saklaw upang hindi ito bumangga sa anumang niroruta na ng opisina. Bago patakbuhin ang anuman, kumpirmahin na ang mga miyembrong port ay walang natitirang address, walang DHCP client, at walang membership sa ibang tulay, at itugma ang addressing ng TAP device sa pamamagitan ng kung ano ang may-ari ng tunnel configuration upang hindi ito magpanumbalik ng address mamaya.

Bakit isang dedikadong port sa bawat bangko

Ang dedikadong wired port ang pumipigil sa eksperimento na maging pagbabago sa buong opisina. Ang management interface ay nagdadala ng SSH, ang default na ruta, at ang panlabas na VPN connection, at wala sa mga iyon ang kabilang sa isang tulay na ang layunin ay ilipat ang mga frame ng laboratoryo.

Ang pagkonekta ng management adapter ay naglalagay sa LAN ng opisina ng isang desisyon sa pagpapasa ang layo mula sa isang development board, at ang board na mali ang asal sa layer two ay eksaktong uri ng device na hindi mo gusto sa segment na iyon. Mas masama ang Wi-Fi adapter: ang pag-bridge ng wireless interface sa infrastructure mode ay hindi kumikilos tulad ng pag-bridge ng Ethernet, at ang kabiguan ay nakakalito sa halip na malinaw.

Panatilihin ang saklaw ng laboratoryo sa labas ng anumang production DHCP scope. Kung ang mga board ay mangangailangan ng dynamic na addressing mamaya, isang awtorisadong allocator na may isang pool ang tanging kaayusan na nananatiling mahuhulaan; ang mga ordinaryong router ng dalawang site na tumutugon sa parehong segment ay gumagawa ng mga address na walang makapagpapaliwanag.

Ang hangganang hindi nililikha ng tulay

Ang pag-bridge ay hindi routing, at hindi rin ito isolation. Ang mga frame na tumatawid sa tulay ay maaari pa ring maabot ang mga filtering hook ng host, depende sa naka-install na bridge-netfilter path, kaya ang epektibong patakaran ay dapat suriin hindi ipagpalagay. Ang pagpapasya na patayin ang firewall dahil nawala ang isang frame ay nagpapalit ng tiyak na bug sa pangkalahatang bug.

Ang IP forwarding sa pagitan ng tulay at bawat management o uplink interface ay dapat manatiling patay o tahasang tanggihan, at ito ay hiwalay na kontrol mula sa membership sa tulay. Ang board na pumipili ng address ng laboratoryo ng computer bilang gateway nito ay sumusubok nang eksakto nito: kung magtagumpay ang transit ng pamamahala, ang hangganang inilaan mo ay hindi kailanman umiral.

Dalawang pamilya pa ang karapat-dapat sa tahasang desisyon. Hindi ginagawang IPv4 lamang ng plano sa addressing ang tulay, kaya ang IPv6 at iba pang EtherType ay nangangailangan ng sarili nilang plano o filter. At ang matagumpay na ping ay walang sinasabi tungkol sa kung ang discovery broadcasts, multicast groups, o jumbo frames ng board ay tatawid sa landas, dahil ang mga iyon ay magkaibang traffic class na may magkaibang default.

Sa huli, ang transport at confidentiality ay dalawang magkaibang pagbili. Ang TAP ay nagdadala ng Ethernet; ang serbisyo ng OpenVPN ay nagbibigay ng proteksyon sa paligid nito. Ang VXLAN overlay ay nagdadala rin ng Ethernet at hindi nagbibigay ng confidentiality sa sarili nito, kaya ang pagpapalit ng isa sa isa pa ay nagbabago ng mga katangian ng seguridad kahit na ang diagram ng topolohiya ay mukhang magkatulad.

Pagpapatuloy at ang mga pagsubok na nagpapatunay

Ang command na na-type nang isang beses pagkatapos kumonekta ay hindi configuration. Gawing permanente ang tulay, ang membership ng port, at ang nag-iisang host address sa pamamagitan ng umiiral na network manager ng computer, at itali ang koneksyon sa paglitaw ng TAP device upang ang muling pagkonekta ay hindi mag-iwan ng tulay na may nawawalang miyembro.

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

Pagkatapos ay subukan kung ano talaga ang kailangan ng mga board sa magkabilang direksyon, muling ikonekta ang tunnel, at i-restart ang isang computer ayon sa aprubadong recovery plan. Kumpirmahin ang tatlong bagay pagkatapos: gumagana pa rin nang nakapag-iisa ang access sa pamamahala, walang lumalabas na doble na address ng laboratoryo, at walang hindi inaasahang production interface ang sumali sa tulay. Ang kombinasyong iyon ang patunay na nanatili ang eksperimento sa loob ng bangko nito.