Dalawang ticket ang dumarating sa parehong araw: isang user ang nangangailangan ng panloob na web app, at isang inhinyero ang nangangailangan na ang bench instrument ay kumilos na parang nasa parehong Ethernet segment. Pareho silang sinasagot ng ilagay sila sa VPN, at doon nagsisimula ang gulo. Ang routed tunnel at bridged tunnel ay nag-uunat ng magkaibang ugnayan, at isa lang sa kanila ang umaangkop sa bawat kahilingan. Ang pagpili ng topolohiya ay desisyon sa access, hindi setting ng cryptography.

Dalawang kahilingan na magkatulad sa desk ng ticket

Ang pangangailangan ng empleyado ay isang serbisyo, maabot sa pamamagitan ng IP, mula sa device na hindi mo kontrolado. Ang pangangailangan ng inhinyero ay nasa antas ng link: inaasahan ng instrument na makita ang mga frame ng Ethernet at pagtuklas sa broadcast, at malamang ay DHCP mula sa segment na inaakala nitong kinalalagyan.

Magkaibang tanong ang mga ito, at ang pagsagot sa dalawa gamit ang bridge ay nagpapalawak ng access ng empleyado sa buong LAN ng opisina nang walang dahilan.

Isulat ang pangangailangan bilang pangungusap bago pumili: aling mga destinasyon, aling mga protocol at aling mga kapares ang dapat mukhang lokal. Kung host at port ang sagot, sakop ito ng routing. Kung ugnayang antas-frame sa mga device na nagsasalita lamang ng broadcast ang sagot, maaaring ang bridge ang tanging opsyon. Anumang nasa gitna ay karapat-dapat sa test segment sa halip na production LAN.

Ang ruta ay mas makitid kaysa pagiging miyembro ng LAN

Ang routed na kliyente ay nakakakuha ng address sa subnet ng tunnel at mga ruta para sa mga prefix na pipiliin mo. Maabot nito ang application server at wala nang iba, kung iyon ang sinasabi ng patakaran. Ang gateway ang nagiging punto ng pagpapatupad, sa kondisyon na dumadaan dito ang bawat kaugnay na landas.

Huwag ipagkamali ang ruta sa pahintulot. Ang pagsasabi sa kliyente kung paano maabot ang subnet ay hindi humahadlang sa pagsubok ng ibang destinasyon.

Ilapat ang access control kung saan talagang maipapatupad nito ang daloy, at panatilihin ang sariling mga pahintulot ng application. Ang malawak na tuntunin sa pagpapasa o nakalimutang pangalawang interface ay maaaring magbigay ng higit sa ipinahihiwatig ng diagram. Basahin ang mga epektibong tuntunin, hindi ang nilayon. Pagkatapos ay subukan ang destinasyong dapat mabigo, dahil ang patakarang walang sinumang sumubok na labagin ay isang haka-haka lamang.

Binabago ng bridge ang tanong sa pagtanggap

Pinagsasama ng bridging ang pisikal na interface at TAP device sa isang software switch, kaya ang malalayong device ay sumasama sa parehong broadcast domain. Tunay na kakayahan ito at tunay na panganib: ang malayong device ay hindi na routed na bisita, ito ay kalahok.

Magpasya kung aling mga device ang maaaring sumama, aling mga uri ng frame ang dapat dumaan at saan hinaharangan ang hindi kagustuhang interaksyon. Ang addressing at awtoridad ng DHCP ay nagiging bahagi ng pinagsasaluhang network, at dalawang DHCP server sa isang segment ay gumagawa ng eksaktong gulo na inaasahan mo.

Para sa instrument, ang nakalaang test segment ay karaniwang mas angkop kaysa LAN ng opisina. Ilagay sa labas ng eksperimento ang access sa pamamahala, at tukuyin kung paano tinatanggal ang pansamantalang kalahok kapag tapos na ang trabaho.

May filtering sa dalawang topolohiya

Ang bridge ay hindi likas na hindi masasala, at ang ruta ay hindi likas na ligtas. Ang filtering ng bridge sa Linux ay may sariling mga hook at sariling sintaks ng tuntunin, at ang tuntuning isinulat para sa routed IP forwarding ay hindi awtomatikong nalalapat sa bridged na mga frame.

Suriin kung ano talaga ang sinusuportahan ng platform bago mangako ng hangganan:

bridge link show
nft list ruleset

Inilalarawan ng TUN at TAP ang trapiko ng interface, hindi ang cipher. Ang pagpapalit ng interface ay walang naaayos doon: ang pagpapatunay ng kapares, ninakaw na key at lumang patakarang cryptographic ay lahat nakakalampas sa pagbabago. Ang dalawang dulo ay nangangailangan pa rin ng mga setting na magkatugma at sinusuportahan pa rin.

Patunayan ang hangganan sa tatlong pagtatangka

Ang pagtanggap ay tatlong obserbasyon, hindi pagsusuri ng diagram. Dapat gumana ang kinakailangang operasyon, dapat mabigo ang walang kaugnayang destinasyon, at ang sariling mga serbisyo ng pamamahala ng gateway ay dapat manatiling hindi maabot.

Patakbuhin ang pinapayagan at ang tinanggihang landas mula sa parehong kliyente, at itala ang dalawa:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

Para sa bridge, idagdag ang mga pagsusuri sa antas ng link: kung dumadaan ang pinapayagang trapiko ng pagtuklas, kung galing sa nilalayong awtoridad ang addressing, at kung wala na ang pansamantalang kalahok pagkatapos alisin. Kapag natutugunan na ng simpleng routed IP ang pangangailangan, ang pagsama sa Ethernet segment ng opisina ay nangangailangan ng hiwalay na katwiran, at dapat itong isulat bago ang pagbabago.

Kaugnay na mga artikulo