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

Два способи з'єднання, один очевидний компроміс

Маршрутизоване з'єднання розглядає домашню лабораторію як віддалену мережу з власною адресацією. Філія запитує префікс лабораторії, тунель переносить ці пакети, а шлюз лабораторії відповідає зі своєї підмережі. У таблиці ARP філії нічого не змінюється, і ніщо з діапазону DHCP лабораторії не доходить до філії.

Мостове з'єднання розтягує один домен рівня 2 на обидва сайти. Протоколи виявлення працюють, пристрої з'являються автоматично, і кожне широкомовне розсилання, кожен ARP-запит і кожен multicast-пакет тепер кандидат на прохід через тунель, тобто великий обсяг трафіку, який несуть протоколи, створені для локального сегмента, а не для WAN з іншим MTU і змінним часом кругового обходу.

Що дає маршрутизація

Перша перевага — радіус ураження. Петля, небажаний DHCP-сервер або лавина широкомовних розсилань залишається на тому сайті, який їх породив, бо маршрутизатор не пересилає широкомовні розсилання. Друга — ясність адресації: префікс філії та префікс лабораторії різні, тому адреса призначення пакета каже, який сайт має відповісти, і правило брандмауера може сказати «філія в підмережу лабораторії» замість «звідусіль куди завгодно».

Третя — це відповідає тому, що тунель насправді переносить. Політика IPsec — це пара префіксів, а шлях пересилання на кожному боці — звичайна IP-маршрутизація з увімкненим пересиланням на шлюзі:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

Ви відмовляєтеся від виявлення широкомовним розсиланням. Це реальна втрата, і її треба замінити свідомо, а не обходити, з'єднуючи все мостом.

Скільки коштує міст

Міст має переносити кадри рівня 2 через тунель, що означає інкапсуляцію на кшталт GRE або VXLAN поверх IPsec замість простого тунелю на основі політик. Щойно це є, два сайти ділять один домен відмови. Spanning tree бачить тунель як канал, широкомовний трафік витрачає смугу тунелю, і будь-який пристрій, який розраховує на сегмент із малою затримкою, поводиться неправильно так, що це важко віднести до однієї зі сторін.

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

Аргумент безпеки зазвичай і вирішує. Міст розширює сегмент, на якому працюють протоколи локального каналу, тому пристрій у філії може говорити з пристроями лабораторії, які ніколи не мали бути доступними ззовні. Якщо в лабораторії є гіпервізор, консоль зберігання та інтерфейс керування в одній плоскій мережі, тепер це один сегмент разом із філією.

Імена без широкомовлення

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

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

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

Зробіть маршрутизований варіант перевірюваним

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

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

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

Схожі статті