Ізольований міст 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 між мостом і кожним інтерфейсом керування або uplink має залишатися вимкненим або бути явно забороненим, і це окремий контроль від членства в мості. Плата, яка вибирає лабораторну адресу комп'ютера як свій шлюз, перевіряє саме це: якщо транзит керування проходить, задуманої межі ніколи не було.

Ще два сімейства заслуговують на явне рішення. План адресації не робить міст лише 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

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