Сайтам, з’єднаним мостом, усе ще потрібне рішення про локальний вихід в інтернет

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

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

Розширення рівня 2 змушує два майданчики виглядати як один домен широкомовлення, тому запити ARP, широкомовні повідомлення DHCP і трафік в одній підмережі проходять через тунель. Це вся послуга, яку він надає. Ніщо в мості не перевіряє адресу призначення, не порівнює її з висхідним каналом сайту і не спрямовує трафік до ближчого виходу. Кожен клієнт і далі сам ухвалює рішення локальний чи віддалений, використовуючи адресу й маску, з якими його налаштовано.

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

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

Рішення IPv4, описане в RFC 1122, просте. Адресат усередині під’єднаної підмережі клієнта досягається напряму, через ARP, а адресат за її межами йде на налаштований шлюз за замовчуванням. Тому трафік однієї підмережі між сайтами може проходити через міст без будь-якої участі маршрутизатора, і тому інтернет-трафік повністю залежить від адреси шлюзу, яку отримав клієнт. Обидві поведінки незалежні, і робочий спільний доступ до файлів доводить лише першу.

Якщо клієнт на малому сайті було налаштовано з маршрутизатором великого сайту, його інтернет-кадри спершу проходять через тунель і виходять звідти.

Зміна власного маршруту за замовчуванням у самого пристрою VPN не переміщує шлюз цього клієнта, бо клієнт узагалі не використовує пристрій як маршрутизатор. Пристрою також потрібен окремий маршрут до свого далекого партнера, щоб тунель, який несе ці кадри, залишався піднятим, і змішування цих двох речей — це те, як розширення моста валить власний транспорт.

Дозвольте DHCP виразити передбачуваний вихід

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

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

Не призначайте одну адресу шлюзу двом незалежно активним маршрутизаторам лише для того, щоб налаштування обох сайтів виглядали однаково. Спільна віртуальна адреса на з’єднаному мостом сегменті — це проєкт резервування першого переходу з власними вимогами, а саморобна версія дає конфлікти ARP, які виглядають як періодична втрата пакетів. Якщо застосунку справді не потрібен спільний сегмент рівня 2, окремі маршрутизовані префікси з локальними шлюзами за замовчуванням простіше експлуатувати і легше пояснювати під час інциденту.

Перевірте чотири речі окремо

Попросіть чотири спостереження, а не одне. Візьміть нову оренду DHCP на кожному сайті й запишіть маршрутизатор і маску, які вона отримала. Дістаньтеся служби в тій самій підмережі на іншому сайті й підтвердьте, що шлях іде через міст, а не через маршрутизований об’їзд. Завантажте щось із публічного інтернету на кожному сайті й підтвердьте, який висхідний канал це переніс. Потім опустіть тунель і подивіться, що зламається, бо сайт, який втрачає весь зв’язок під час відмови моста, залежав від далекого шлюзу, і ніхто цього не помічав.

Ці чотири результати скажуть, чи є у вас міст між сайтами, локальний вихід або випадковий зворотний канал, і на їх збір піде десять хвилин.

Принцип проєктування не показний: міст вирішує доступність, DHCP вирішує шлюз, а таблиця маршрутизації на пристрої вирішує власний шлях тунелю. Тримайте ці три речі в окремих розмовах, бо одна зміна, що намагається виправити всі три, зазвичай ламає дві.