Злучаныя мастам сайты ўсё яшчэ патрабуюць рашэння пра лакальны выхад у інтэрнэт

Пашырэнне VLAN прайшло чыста: хасты на абодвух сайтах бачаць адзін аднаго, агульны доступ да файлаў працуе, прынтары адказваюць. Потым нехта на меншым сайце заўважае, што кожнае спампоўванне ідзе праз інтэрнэт-лінію іншага сайта, і заяўка прыходзіць як скарга на прапускную здольнасць. Мост зрабіў менавіта тое, што ад яго патрабавалі. Ён пераносіў кадры паміж двума будынкамі і ніколі не меў меркавання, які маршрутызатар гэтыя кадры павінны выкарыстоўваць для інтэрнэту.

Мост пераносіць кадры, а не рашэнні

Пашырэнне ўзроўню 2 робіць дзве пляцоўкі адным шырокавяшчальным даменам, таму запыты ARP, шырокавяшчальныя пакеты DHCP і трафік у межах адной падсеткі праходзяць праз тунель. Гэта ўся паслуга, якую ён дае. Нішто ў мосце не правярае адрас прызначэння, не параўноўвае яго з каналам сайта і не накіроўвае трафік да бліжэйшага выхаду. Кожны кліент па-ранейшаму сам вырашае, лакальны ці аддалены адрас, выкарыстоўваючы адрас і маску, з якімі ён быў наладжаны.

Пастаўце два маршрутызатары на гэтую агульную падсетку, і абодва стануць верагоднымі шлюзамі, незалежна ад таго, ці блізкі хоць адзін з іх да кліента, які ім карыстаецца.

Як кліент выбірае свой шлюз

Рашэнне IPv4, апісанае ў RFC 1122, простае. Прызначэнне ўнутры падключанай падсеткі кліента дасягаецца напрамую праз ARP, а прызначэнне па-за ёй ідзе на наладжаны шлюз па змаўчанні. Таму трафік у межах адной падсеткі паміж сайтамі можа праходзіць праз мост без удзелу маршрутызатара, і таму інтэрнэт-трафік цалкам залежыць ад адраса шлюза, які атрымаў кліент. Гэтыя дзве паводзіны незалежныя, і працоўны агульны доступ да файлаў даказвае толькі першую.

Калі кліент на малым сайце быў наладжаны на маршрутызатар вялікага сайта, яго інтэрнэт-кадры спачатку праходзяць праз тунель і выходзяць адтуль.

Змена ўласнага маршруту па змаўчанні ў прылады VPN не перамяшчае шлюз гэтага кліента, бо кліент зусім не выкарыстоўвае прыладу як маршрутызатар. Прыладзе таксама патрэбны асобны маршрут да свайго далёкага партнёра, каб тунель, які пераносіць гэтыя кадры, заставаўся ўзнятым, і менавіта блытаніна паміж гэтымі двума рэчамі прыводзіць да таго, што пашырэнне моста валіць уласны транспарт.

Хай DHCP выказвае меркаваны выхад

Опцыя 3 у адказе DHCP дае спіс адрасоў маршрутызатараў у падсетцы кліента ў парадку перавагі, і кліенты звычайна бяруць першы, які адказаў. Механізм добры; праблемы ўзнікаюць з тым, хто ім валодае. Запісвайце, што фактычная арэнда дае на кожным сайце, замест таго каб меркаваць, што найбліжэйшы сервер DHCP выдасць найбліжэйшы шлюз.

Трымайце адзін узгоджаны размеркавальнік або два, яўна наладжаныя на аднолькавую палітыку, і прызначце палітыцы ўладальніка. Другі незалежны размеркавальнік, дададзены на аддаленым сайце, не стварае лакальнасці, ён стварае дзве ўлады для аднаго шырокавяшчальнага дамена.

Не прызначайце адзін адрас шлюза двум незалежна актыўным маршрутызатарам толькі дзеля таго, каб налады абодвух сайтаў выглядалі аднолькава. Агульны віртуальны адрас на злучаным мастом сегменце — гэта схема рэзервіравання першага скачка з уласнымі патрабаваннямі, а самаробная версія дае канфлікты ARP, якія выглядаюць як перамежныя страты пакетаў. Калі праграма насамрэч не патрабуе агульнага сегмента ўзроўню 2, асобныя маршрутызаваныя прэфіксы з лакальнымі шлюзамі па змаўчанні прасцей эксплуатаваць і лягчэй тлумачыць падчас інцыдэнту.

Праверце чатыры рэчы асобна

Прасіце чатыры назіранні, а не адно. Вазьміце свежую арэнду DHCP на кожным сайце і запішыце атрыманы маршрутызатар і маску. Дасягніце сэрвісу ў межах той жа падсеткі на іншым сайце і пацвердзіце, што шлях ідзе праз мост, а не праз маршрутызаваны аб’езд. Спампуйце што-небудзь з публічнага інтэрнэту на кожным сайце і пацвердзіце, які канал гэта перанёс. Потым апусце тунель і паглядзіце, што зламаецца, бо сайт, які губляе ўсю сувязь пры адмове моста, залежаў ад далёкага шлюза, і ніхто гэтага не заўважаў.

Гэтыя чатыры вынікі скажуць вам, ці ў вас міжсайтавы мост, лакальны выхад або выпадковы зваротны канал, і на іх збор спатрэбіцца дзесяць хвілін.

Прынцып дызайну неэфектны: маставанне вырашае дасяжнасць, DHCP вырашае шлюз, а табліца маршрутызацыі на прыладзе вырашае ўласны шлях тунеля. Трымайце гэтыя тры рэчы ў асобных размовах, бо адно змяненне, якое спрабуе выправіць усе тры, звычайна ламае два.