Поделюсь опытом использования одного ПК в двух VLAN'ах – проблемы с DNS и изоляцией. В общем, решил я побороться с растущим количеством устройств в сети и решил использовать один компьютер для разных VLAN'ов. Звучит вроде как "гениально", правда? Ага… В

RSS

Поделюсь опытом использования одного ПК в двух VLAN'ах – проблемы с DNS и изоляцией. В общем, решил я побороться с растущим количеством устройств в сети и решил использовать один компьютер для разных VLAN'ов. Звучит вроде как "гениально", правда? Ага… В, wifiman

marbol

Guest

13.02.2025 17:48:00

Привет всем!

Это мой первый пост здесь. У меня две VLAN на моей сети:

* **VLAN 1 (192.168.1.0/24)** - Общего назначения, на ней находятся большинство устройств.
* **VLAN 2 (192.168.2.0/24)** - Используется для управления серверами, интерфейсами IPMI и т.д.

VLAN изолированы, так что любое устройство в VLAN 1 не видит интерфейсы управления в VLAN 2 и наоборот.

Я хочу предоставить Linux PC в моей сети доступ к обеим VLAN, чтобы он мог получать доступ к интерфейсам IPMI в VLAN 2 и к любым другим устройствам в VLAN 1, сохраняя при этом изоляцию VLAN.

Все устройства подключены к коммутатору, в данном случае Flex Mini 2.5g 5, и он сконфигурирован как показано в следующей таблице:

| Порт | Имя хоста | Описание | Native | Tagged | IP
|---|---|---|---|---|---|
| 1 | linuxpc | Linux PC | 1 | 2 |
| 2 | server | Сервер | 1 | | 192.168.1.33
| 3 | ipmi | IPMI сервера | 2 | | 192.168.2.67
| 4 | macmini | Mac Mini | 1 | | 192.168.1.24
| 5 | | UDM Uplink | | 1, 2 |

Чтобы Linux PC мог общаться с устройствами VLAN 2, я настроил NetworkManager с интерфейсом VLAN, что дало мне следующее:

| Интерфейс | VLAN | IP
|---|---|---|
| eno1 | - | 192.168.1.49
| vlan2@eno1 | 2 | 192.168.2.51

Весь трафик, покидающий порт eno1, не имеет тегов и, следовательно, назначается родной VLAN коммутатором. Весь трафик, покидающий порт vlan2@eno1, помечен номером 2 и принимается коммутатором.

Что работает на данный момент:

Я могу пинговать любое устройство на каждой VLAN с Linux PC, так как NetworkManager настраивает правила маршрутизации, которые отправляют весь трафик для сети 192.168.1.0 через eno1 и весь трафик для 192.168.2.0 через vlan2@eno1.

Mac Mini не может пинговать IPMI сервер, и наоборот.

Каждому интерфейсу присвоен собственный IP-адрес в соответствии с его VLAN, поэтому DHCP работает как ожидается.

Однако я столкнулся со следующими проблемами:

Если я выполняю DNS-запрос с Linux PC `nslookup linuxpc 192.168.1.1` (т.е. запрос отправляется через eno1), я получаю 192.168.2.51, что не имеет смысла для меня. Должен был бы вернуться 192.168.1.49, верно? Я бы ожидал получить обратно 192.168.2.51, если бы отправил запрос на 192.168.2.1, и, следовательно, покинул бы VLAN2@eno1. Более того, любое устройство в VLAN 1 теперь разрешает linuxpc в 192.168.2.51.

VLAN изолированы, поэтому я бы ожидал, что DNS-запрос с Mac Mini 'nslookup ipmi' вернет ничего, вместо этого он возвращает 192.168.2.67, несмотря на то, что он не может получить доступ к VLAN 2. Это не большая проблема, потому что если я пингую 192.168.2.67 с Mac Mini, я не получаю ответа, как и ожидалось.

Я могу пинговать 192.168.2.51 с Mac Mini или любого другого устройства в VLAN 1. После использования 'tcpdump -i <iface> -n icmp' для отображения входящих пингов на Linux PC. Я вижу, что пинги, отправленные на 192.168.2.51, приходят на eno1, а не на vlan3@eno1, проверка показывает, что ни один запрос не содержит входящих пингов. Это абсолютно не должно быть разрешено.

Консоль UDM не показывает никаких признаков того, что у Linux PC есть другой DHCP-аренд на другой VLAN, консоль продолжает показывать Linux PC с IP-адресом 192.168.1.49.

Я подумал, что это потому, что как eno1, так и vlan2@eno1 имеют одинаковый MAC-адрес, но после некоторых исследований я узнал, что невозможно изменить MAC VLAN-интерфейса с помощью NetworkManager, и он всегда наследует MAC родительского интерфейса. Однако это не должно быть проблемой, так как это один и тот же NIC на Linux PC, поэтому таблицы маршрутизации MAC все еще остаются действительными.

Я был бы очень благодарен за помощь в этом вопросе.

С уважением.

acebmxer

Guest

13.02.2025 18:45:00

Тебе точно стоит избегать подключения ПК к двум разным сетям. То же самое касается и прямого подключения (hardwiring) и подключения по Wi-Fi. Это может привести к сетевым петлям. Правильный способ — через правила брандмауэра.

mister_ust

Guest

02.03.2025 16:18:00

Я уже сталкивался с похожей проблемой, когда у меня Pi-hole был настроен с двумя отдельными интерфейсами. В этом случае Pi-hole выступал моим DNS-сервером и отвечал на все запросы. Даже когда он привязывается к одному интерфейсу (например, eth0), он все равно может привязываться к IP 0.0.0.0, что позволит ему получать трафик с интерфейса eth1. У Pi-hole есть специальные возможности для предотвращения проблем, описанных в твоем посте. Есть настройка под названием "localise-queries", которая будет возвращать IP, соответствующий запросившему сабнету, если у запрашиваемого хоста несколько IP-адресов. (Это всё на самом деле делегируется dnsmasqd, но суть остается прежней).

marbol

Guest

15.02.2025 17:23:00

Обновление: Я разобрался с частью проблемы. Оказывается, Linux позволяет интерфейсам отвечать на ARP-запросы от имени других интерфейсов. Mac Mini рассылал бы ARP-запрос на 192.168.2.51, на который eno1 охотно отвечал от имени vlan2@eno1. Поскольку у обоих интерфейсов был один и тот же MAC-адрес, это означало, что пакеты имели правильный маршрут от Mac Mini к Linux PC, обходя UDM. Решением было включить sysctl arp_ignore, который запрещает интерфейсам отвечать на ARP-запросы для IP-адресов, к которым у них нет доступа. Проблемы с DNS всё ещё остались, но это точно вызвано UDM.

marbol

Guest

13.02.2025 21:10:00

Ну, я не сетевой гуру, но моя логика была в том, что тогда неважно, какое устройство подключено к этому порту, если оно поддерживает VLAN, то оно может получить доступ к чему угодно в VLAN 2. Это также позволяет мне логически разделять сервисы на Linux PC между eno1 и vlan2@eno1. Однако, как ты и предложил, я попробовал настроить правило брандмауэра. Простое правило не позволяет двусторонний трафик, но два расширенных правила для отправки и приема работают отлично, при условии, что Linux PC использует статический IP. Все равно хотел бы понять, почему мой первый подход не работает, похоже, UDM не в восторге от того, что одно и то же устройство (один и тот же MAC и то же имя хоста) появляется в нескольких VLAN, даже если оно подключено по одному физическому соединению к одному и тому же физическому сетевому адаптеру. Если я использую второй сетевой адаптер на Linux PC и физически разделяю его на другой VLAN, подключив к другому порту на коммутаторе, настроенном на Native VLAN 2, проблемы с изоляцией решаются, но не проблемы с DNS, потому что сеть думает, что в одной сети есть два разных устройства с одним и тем же именем хоста.

acebmxer Guest	#6 13.02.2025 19:19:00 Да, ты прав. Кажется, я зациклился в своей собственной сети 😀

FrankNicklin

Guest

13.02.2025 18:49:00

Не должно быть проблем, если вы находитесь в разных подсетях. Возможно, цикл возникнет, если и Ethernet, и Wi-Fi подключаются к одной и той же подсети. Хотя, если честно, у меня никогда не возникало проблем на моём Mac в сетях Unifi. Когда я в офисе, мой Wi-Fi всегда активен, и я подключаюсь к своему Apple-дисплею, у которого есть Ethernet, и это никогда не приводило к проблемам с циклами, когда оба подключения активны.

schearer_tech Guest	#8 13.02.2025 18:19:00 Я, конечно, не эксперт по VLAN и вообще ничего не знаю про Linux, так что отнеситесь к этому совету с изрядной долей скепсиса. Зачем вам создавать 2 интерфейса на вашем Linux-компьютере? Должен быть только один интерфейс на VLAN по умолчанию. А потом просто создайте правило файрвола, чтобы разрешить трафик в VLAN 2 только с конкретного Linux-клиента. Может, вы всё сделали правильно, просто я бы сделал по-другому. Мои два цента, хотя, скорее всего, я и не прав.

Читают тему (гостей: 1)