Проширувањето на VLAN помина чисто: домаќините на двете локации се гледаат, споделувањето датотеки работи и печатачите одговараат. Потоа некој на помалата локација забележува дека секое преземање ја користи интернет линијата на другата локација, и тикетот пристигнува како жалба за пропусен опсег. Мостот го направи точно она што му беше побарано. Пренесуваше рамки меѓу две згради и никогаш немал мислење за тоа кој рутер тие рамки треба да го користат за интернет.

Мостот пренесува рамки, не одлуки

Проширувањето на слој 2 прави две места да изгледаат како еден домен за емитување, па барањата ARP, емитувањата DHCP и сообраќајот во истата подмрежа поминуваат низ тунелот. Тоа е целата услуга што ја дава. Ништо во мостот не проверува одредишна адреса, не ја споредува со горната врска на локацијата и не го насочува сообраќајот кон поблискиот излез. Секој клиент сè уште сам одлучува локално или далечински користејќи ја адресата и маската со кои бил конфигуриран.

Ставете два рутери на таа споделена подмрежа и двата стануваат веројатни порти, без разлика дали некој од нив е близу до клиентот што го користи.

Како клиентот ја избира својата порта

Одлуката IPv4 опишана во RFC 1122 е едноставна. Одредиште во поврзаната подмрежа на клиентот се достигнува директно, со ARP, а одредиште надвор од неа оди на конфигурираната стандардна порта. Затоа сообраќајот во истата подмрежа меѓу локациите може да го помине мостот без никакво учество на рутер, и затоа интернет сообраќајот целосно зависи од адресата на портата што клиентот ја добил. Двете однесувања се независни, а работното споделување датотеки го докажува само првото.

Ако клиент на малата локација бил конфигуриран со рутерот на големата локација, неговите интернет рамки прво поминуваат низ тунелот и излегуваат оттаму.

Менувањето на сопствената стандардна рута на VPN уредот не ја поместува портата на тој клиент, бидејќи клиентот воопшто не го користи уредот како рутер. На уредот му треба и посебна рута до неговиот далечен партнер за да остане тунелот што ги пренесува тие рамки, а мешањето на двете е начинот на кој проширувањето на мостот го соборува сопствениот транспорт.

Дозволете DHCP да го изрази предвидениот излез

Опција 3 во DHCP одговорот дава список на адреси на рутери во подмрежата на клиентот, по ред на предност, и клиентите обично ја земаат првата што одговара. Механизмот е добар; сопственоста е местото каде дизајните грешат. Запишете што дава вистински закуп на секоја локација наместо да претпоставувате дека најблискиот DHCP сервер ќе ја даде најблиската порта.

Водете еден координиран распределувач или два што се експлицитно конфигурирани за истата политика, и дајте и сопственик на политиката. Вториот независен распределувач додаден на далечната локација не создава локалност, туку создава два авторитета за истиот домен за емитување.

Не доделувајте една адреса на порта на два независно активни рутери само за да изгледаат идентични поставките на двете локации. Споделената виртуелна адреса преку мост-поврзан сегмент е дизајн за резервирање на првиот чекор со свои барања, а рачно изработената верзија произведува ARP конфликти што изгледаат како повремено губење пакети. Ако апликацијата навистина не бара споделен сегмент на слој 2, одделни рутирани префикси со локални стандардни порти се поедноставни за работа и полесно се објаснуваат за време на инцидент.

Тестирајте ги четирите работи одделно

Побарајте четири набљудувања, не едно. Земете нов DHCP закуп на секоја локација и запишете го рутерот и маската што ги добил. Достигнете услуга во истата подмрежа на другата локација и потврдете дека патеката е мостот, а не рутиран обиколен пат. Преземете нешто од јавниот интернет на секоја локација и потврдете која горна врска го пренела. Потоа спуштете го тунелот и видете што се крши, бидејќи локација што го губи целото поврзување кога мостот откажува зависела од далечната порта, а никој не забележал.

Тие четири резултати ви кажуваат дали имате мост меѓу локации, локален излез или случајно враќање, и нивното собирање трае десет минути.

Принципот на дизајн не е гламурозен: мостот одлучува за достапноста, DHCP одлучува за портата, а рутирачката табела на уредот одлучува за сопствената патека на тунелот. Држете ги трите во одделни разговори, бидејќи една промена што се обидува да ги поправи сите три обично крши две.

Поврзани статии