Изолированный мост TAP между двумя платами через OpenVPN

Две отладочные платы должны делить один сегмент Ethernet, хотя их стенды находятся в разных зданиях. Туннель уже существует и уже передаёт Ethernet, поэтому оставшаяся работа выглядит как три команды и таковой не является. Что хост делает с кадром, прошедшим через мост, где находится собственный адрес компьютера и какую границу мост не создаёт — это три отдельных факта, и ошибка во втором обычно и становится причиной того, что лаборатория работает с перебоями, а доступ к управлению тихо ухудшается. Ни один из этих трёх фактов не виден на схеме топологии.

Путь ниже предполагает аутентифицированное соединение TAP между двумя компьютерами Linux, один выделенный проводной порт на стенд и интерфейс управления, не входящий в эксперимент. Порядок важен: сначала кадры, затем адреса, в конце граница.

Что мост на самом деле переносит

Мост — это коммутатор, реализованный в программном обеспечении. Он изучает, какой MAC-адрес появляется за каким портом-участником, и пересылает кадры между участниками, не обращаясь к таблице маршрутизации IP. Ничего в этом описании не включает подсеть, шлюз или маршрут по умолчанию, поэтому включение пересылки IP не создаёт этого подключения и поэтому ping может проходить, пока другой трафик всё ещё не проходит. Плата может достичь партнёра вообще без настроенного маршрута по умолчанию, что удивляет тех, кто ожидает, что второй уровень будет вести себя как третий.

Каждый компьютер добавляет мосту один проводной порт и устройство TAP в тот же мост, поэтому кадр с платы входит в локальный порт, передаётся на устройство TAP, проходит через туннель, приходит на устройство TAP партнёра и передаётся на его плату. Туннель — такой же порт-участник, как любой другой, и мост не знает и не заботится о том, что за ним стоит VPN. Именно эта симметрия делает пример простым для рассуждения: у каждой стороны один порт, обращённый к лаборатории, и один порт туннеля, и ни одна сторона не является особенной.

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

Одинаковые имена на обоих компьютерах — это локальные имена, а не общие объекты. Между стендами есть один путь Ethernet, без второго кабеля и без второго туннеля, замыкающего петлю; мост, который видит один и тот же MAC, приходящий на два порта, с удовольствием будет передавать по кругу.

Адресуйте мост, а не его порты-участники

Идентичность компьютера в лабораторном сегменте принадлежит устройству моста. Порты-участники остаются без адреса, потому что порт — это передающий участник, и адрес на нём создал бы второго, конкурирующего владельца того же сегмента. Это та поправка, которую большинство самодельных рецептов делают неправильно: они адресуют устройство TAP и мост, а затем гадают, до какого из них партнёр действительно доходит.

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

Партнёр использует ту же форму с другим адресом хоста, а платы берут адреса в том же диапазоне, используя адрес моста компьютера как следующий переход, если он им нужен. Используйте диапазоны документации, пока план не согласован, и резервируйте диапазон, чтобы он не конфликтовал с чем-либо, что офис уже маршрутизирует. Прежде чем запускать что-либо из этого, подтвердите, что порты-участники не несут остаточного адреса, клиента DHCP и членства в другом мосте, и согласуйте адресацию устройства TAP через то, что владеет конфигурацией туннеля, чтобы оно позже не восстановило адрес.

Почему один выделенный порт на стенд

Именно выделенный проводной порт не даёт эксперименту стать изменением для всего офиса. Интерфейс управления несёт SSH, маршрут по умолчанию и внешнее подключение VPN, и ничто из этого не принадлежит мосту, цель которого — переносить лабораторные кадры.

Подключение адаптера управления ставит офисную LAN на расстояние одного решения о пересылке от отладочной платы, а плата, которая плохо ведёт себя на втором уровне, — именно тот тип устройства, который вы не хотите видеть в этом сегменте. Адаптер Wi-Fi ещё хуже: объединение беспроводного интерфейса в режиме инфраструктуры в мост ведёт себя не как объединение Ethernet, и сбой получается запутанным, а не чистым.

Держите лабораторный диапазон вне любого производственного диапазона DHCP. Если платам позже понадобится динамическая адресация, единственный уполномоченный распределитель с одним пулом — единственная схема, остающаяся предсказуемой; обычные маршрутизаторы двух площадок, отвечающие в одном сегменте, создают адреса, которые никто не может объяснить.

Граница, которую мост не создаёт

Объединение в мост — это не маршрутизация и не изоляция. Кадры, проходящие через мост, всё ещё могут достигать хуков фильтрации хоста в зависимости от установленного пути bridge-netfilter, поэтому действующую политику нужно проверять, а не предполагать. Отключение межсетевого экрана из-за одного потерянного кадра меняет конкретную ошибку на общую.

Пересылка IP между мостом и каждым интерфейсом управления или аплинком должна оставаться выключенной или быть явно запрещена, и это отдельный контроль от членства в мосте. Плата, выбирающая лабораторный адрес компьютера в качестве шлюза, проверяет именно это: если транзит управления проходит, задуманной границы никогда не было.

Ещё два семейства заслуживают явного решения. План адресации не делает мост только IPv4, поэтому IPv6 и другие EtherType нуждаются в собственном плане или фильтре. А успешный ping ничего не говорит о том, пройдут ли по пути широковещательные запросы обнаружения платы, группы multicast или jumbo-кадры, потому что это разные классы трафика с разными значениями по умолчанию.

Наконец, транспорт и конфиденциальность — это две разные покупки. TAP переносит Ethernet; служба OpenVPN обеспечивает защиту вокруг него. Наложение VXLAN тоже переносит Ethernet и само по себе не обеспечивает конфиденциальности, поэтому замена одного другим меняет свойства безопасности, даже когда схема топологии выглядит одинаково.

Устойчивость и тесты, которые её доказывают

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

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

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