Ang mga site na naka-bridge ay kailangan pa rin ng desisyon sa lokal na labasan ng internet

Malinis na dumaan ang pagpapalawak ng VLAN: nagkikita ang mga host sa dalawang site, gumagana ang pagbabahagi ng file, at sumasagot ang mga printer. Pagkatapos may makakapansin sa mas maliit na site na gumagamit ang bawat download ng internet line ng kabilang site, at dumarating ang ticket bilang reklamo sa bandwidth. Ginawa ng bridge ang eksaktong ipinag-utos. Nagdala ito ng mga frame sa pagitan ng dalawang gusali, at hindi kailanman nagkaroon ng opinyon kung aling router ang dapat gamitin ng mga frame na iyon para sa internet.

Nagdadala ang bridge ng frame, hindi desisyon

Ang pagpapalawak sa layer 2 ay nagpapakita ng dalawang lokasyon na parang isang broadcast domain, kaya ang mga kahilingan ng ARP, broadcast ng DHCP at trapiko sa parehong subnet ay dumadaan sa tunnel. Iyon ang buong serbisyong ibinibigay nito. Wala sa bridge ang sumusuri ng address ng destinasyon, naghahambing nito sa uplink ng site o naglilihis ng trapiko patungo sa mas malapit na labasan. Bawat kliyente ay gumagawa pa rin ng sariling lokal o malayong desisyon gamit ang address at mask na na-configure dito.

Maglagay ng dalawang router sa pinagsasaluhang subnet na iyon at parehong magiging makatwirang gateway, may malapit man o wala sa kliyenteng gumagamit nito.

Paano pumipili ang kliyente ng gateway nito

Ang desisyon sa IPv4 na inilarawan sa RFC 1122 ay simple. Ang destinasyon sa loob ng konektadong subnet ng kliyente ay naaabot nang direkta, gamit ang ARP, at ang destinasyon sa labas nito ay pumupunta sa naka-configure na default gateway. Kaya nga ang trapiko sa parehong subnet sa pagitan ng mga site ay makakadaan sa bridge nang walang anumang partisipasyon ng router, at kaya nga ang trapiko ng internet ay lubos na nakadepende sa address ng gateway na natanggap ng kliyente. Ang dalawang pag-uugali ay independiyente, at ang gumaganang pagbabahagi ng file ay nagpapatunay lamang ng una.

Kung ang kliyente sa maliit na site ay na-configure sa router ng malaking site, ang mga frame ng internet nito ay dadaan muna sa tunnel at lalabas doon.

Ang pagbabago ng sariling default route ng VPN appliance ay hindi naglilipat ng gateway ng kliyenteng iyon, dahil hindi ginagamit ng kliyente ang appliance bilang router. Kailangan din ng appliance ng hiwalay na ruta patungo sa malayong peer nito upang manatili ang tunnel na nagdadala ng mga frame na iyon, at ang paghahalo ng dalawang ito ang paraan ng pagbagsak ng sariling transportasyon ng isang pagpapalawak ng bridge.

Hayaang ipahayag ng DHCP ang nilalayong labasan

Ang opsyon 3 sa tugon ng DHCP ay nagbibigay ng listahan ng mga address ng router sa subnet ng kliyente, ayon sa pagkakasunod-sunod ng priyoridad, at karaniwang kinukuha ng mga kliyente ang unang tumutugon. Maayos ang mekanismo; ang pagmamay-ari ang lugar kung saan nagkakamali ang mga disenyo. Itala kung ano ang ibinibigay ng tunay na lease sa bawat site sa halip na ipagpalagay na ang pinakamalapit na DHCP server ang magbibigay ng pinakamalapit na gateway.

Magpatakbo ng isang koordinadong allocator, o dalawang tahasang naka-configure para sa parehong patakaran, at bigyan ng may-ari ang patakaran. Ang pangalawang independiyenteng allocator na idinagdag sa malayong site ay hindi lumilikha ng lokalidad, lumilikha ito ng dalawang awtoridad para sa parehong broadcast domain.

Huwag magtalaga ng isang address ng gateway sa dalawang independiyenteng aktibong router para lang magmukhang magkapareho ang mga setting ng dalawang site. Ang pinagsasaluhang virtual address sa isang segment na naka-bridge ay isang disenyo ng redundancy sa unang hop na may sariling mga pangangailangan, at ang gawang-kamay na bersyon ay gumagawa ng mga salungatan sa ARP na mukhang paminsan-minsang pagkawala ng packet. Kung talagang hindi kailangan ng aplikasyon ang pinagsasaluhang layer 2 segment, ang hiwalay na niruruta na prefix na may lokal na default ay mas simple pangasiwaan at mas madaling ipaliwanag kapag may insidente.

Subukan ang apat na bagay nang hiwalay

Humingi ng apat na obserbasyon, hindi isa. Kumuha ng bagong DHCP lease sa bawat site at itala ang router at mask na natanggap. Abutin ang serbisyo sa parehong subnet sa kabilang site at kumpirmahin na ang landas ay ang bridge at hindi isang nirurutang liko. Kumuha ng isang bagay mula sa pampublikong internet sa bawat site at kumpirmahin kung aling uplink ang nagdala nito. Pagkatapos ibagsak ang tunnel at tingnan kung ano ang masisira, dahil ang site na nawawalan ng lahat ng koneksyon kapag nabigo ang bridge ay umaasa pala sa malayong gateway nang walang nakakapansin.

Sinasabi ng apat na resultang iyon kung mayroon kang bridge sa pagitan ng mga site, lokal na labasan o aksidenteng backhaul, at sampung minuto ang pagkuha ng mga ito.

Ang prinsipyo ng disenyo ay hindi kislap: ang pag-bridge ang nagtatakda ng maabot, ang DHCP ang nagtatakda ng gateway, at ang routing table sa appliance ang nagtatakda ng sariling landas ng tunnel. Panatilihin ang tatlo sa hiwalay na usapan, dahil ang isang pagbabagong sumusubok ayusin ang tatlo ay karaniwang sumisira ng dalawa.