Изолиран 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 overlay също пренася Ethernet и сам по себе си не осигурява поверителност, затова замяната на едното с другото променя свойствата за сигурност, дори когато диаграмата на топологията изглежда еднаква.

Устойчивост и тестовете, които я доказват

Команда, въведена веднъж след свързване, не е конфигурация. Направете моста, членството на портовете и единствения адрес на хоста постоянни чрез съществуващия мрежов мениджър на компютъра и обвържете прикачването с появата на TAP устройството, за да не остави повторното свързване мост с изчезнал член.

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

След това тествайте какво всъщност им е нужно на платките в двете посоки, свържете отново тунела и рестартирайте един компютър по одобрения план за възстановяване. След това потвърдете три неща: достъпът за управление все още работи независимо, не се появява дублиран лабораторен адрес и неочакван производствен интерфейс не се е присъединил към моста. Тази комбинация е доказателството, че експериментът е останал в рамките на своя стенд.