Мостово свързаните обекти все още се нуждаят от решение за локален интернет изход

Разширението на VLAN мина чисто: хостовете в двата обекта се виждат, файловите споделяния работят, принтерите отговарят. После някой в по-малкия обект забелязва, че всяко изтегляне използва интернет линията на другия обект, и заявката пристига като оплакване за честотна лента. Мостът направи точно това, което му беше поискано. Пренасяше кадри между две сгради и никога не изрази мнение кой рутер трябва да използват тези кадри за интернет.

Мостът пренася кадри, не решения

Разширение на слой 2 прави две локации да изглеждат като един broadcast домейн, затова ARP заявките, DHCP broadcast-ите и трафикът в същата подмрежа преминават през тунела. Това е цялата услуга, която той предоставя. Нищо в моста не проверява адрес на местоназначение, не го сравнява с uplink-а на обекта и не насочва трафика към по-близкия изход. Всеки клиент все още взема собствено решение локално или отдалечено, използвайки адреса и маската, с които е конфигуриран.

Поставете два рутера в тази споделена подмрежа и двата стават възможни шлюзове, независимо дали някой от тях е близо до клиента, който го използва.

Как клиентът избира своя шлюз

Решението за IPv4, описано в RFC 1122, е просто. Местоназначение вътре в свързаната подмрежа на клиента се достига директно с ARP, а местоназначение извън нея отива към конфигурирания шлюз по подразбиране. Затова трафикът в същата подмрежа между обектите може да преминава през моста без никакво участие на рутер и затова интернет трафикът зависи изцяло от адреса на шлюза, който клиентът е получил. Двете поведения са независими и работещото файлово споделяне доказва само първото.

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

Промяната на собствения маршрут по подразбиране на VPN устройството не мести шлюза на този клиент, защото клиентът изобщо не използва устройството като рутер. Устройството се нуждае и от отделен маршрут до своя далечен партньор, за да остане тунелът, пренасящ тези кадри, активен, и объркването на двете е начинът, по който едно разширение на мост събаря собствения си транспорт.

Нека DHCP изразява предвидения изход

Опция 3 в DHCP отговора предоставя списък с адреси на рутери в подмрежата на клиента по ред на предпочитание и клиентите обикновено вземат първия, който отговори. Механизмът е наред; собствеността е там, където дизайните се объркват. Записвайте какво дава реален lease във всеки обект, вместо да предполагате, че най-близкият DHCP сървър ще раздаде най-близкия шлюз.

Поддържайте един координиран разпределител или два, изрично конфигурирани за една и съща политика, и дайте на политиката собственик. Втори независим разпределител, добавен в отдалечения обект, не създава локалност, а създава два органа за един и същ broadcast домейн.

Не назначавайте един адрес на шлюз на два независимо активни рутера само за да изглеждат настройките на двата обекта еднакви. Споделен виртуален адрес през мостово свързан сегмент е дизайн за резервиране на първи хоп със собствени изисквания, а ръчно изработената версия произвежда ARP конфликти, които изглеждат като периодична загуба на пакети. Ако приложението наистина не се нуждае от споделен сегмент на слой 2, отделни маршрутизирани префикси с локални шлюзове по подразбиране са по-прости за експлоатация и по-лесни за обяснение по време на инцидент.

Тествайте четирите неща поотделно

Поискайте четири наблюдения, не едно. Вземете нов DHCP lease във всеки обект и запишете рутера и маската, които е получил. Достигнете услуга в същата подмрежа в другия обект и потвърдете, че пътят е мостът, а не маршрутизиран обход. Изтеглете нещо от публичния интернет във всеки обект и потвърдете кой uplink го е пренесъл. След това свалете тунела и вижте какво се чупи, защото обект, който губи цялата свързаност при отказ на моста, е зависел от далечния шлюз, без някой да забележи.

Тези четири резултата ви казват дали имате мост между обектите, локален изход или случаен обратен канал, и събирането им отнема десет минути.

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