Есть два способа дать филиалу доступ к домашней лаборатории, и разница не в настройке. Можно маршрутизировать между разными префиксами, чтобы каждый сайт сохранял свой широковещательный домен, или соединить две локальные сети в одну мостом, чтобы широковещательные рассылки и трафик обнаружения вели себя так, будто все находятся в одной комнате. Маршрутизация — это решение, которое выдерживает соприкосновение с реальной сетью. Мост — это решение, которое делает первую неделю простой, а первую аварию интересной. Сравнение ниже о том, что даёт каждый вариант и сколько он стоит, а затем о том, как сделать маршрутизируемый вариант проверяемым.

Два способа соединения, один очевидный компромисс

Маршрутизируемое соединение рассматривает домашнюю лабораторию как удалённую сеть с собственной адресацией. Филиал запрашивает префикс лаборатории, туннель переносит эти пакеты, а шлюз лаборатории отвечает из своей подсети. В таблице 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 описывают путь пакетов, который должен работать на каждой стороне.

Затем проверьте и запрещённое назначение. Пользователю филиала, которому нужно одно приложение, не нужна консоль гипервизора, и единственный способ узнать, что политика настоящая, — попробовать именно то, что она должна запретить. Запишите префиксы, зависимость от резолвера и результаты проверок, и будущее изменение на любом из сайтов можно просмотреть за минуты, а не восстанавливать по памяти.

Похожие статьи