Шлюз с несколькими vlan

Автор imelya, 23 августа 2019, 18:46:08

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

imelya

Добрый день!

Прошу помощи, подсказки.

Имеется шлюз с debian 10, сетевая карта intel 82575EB. Один физический интерфейс смотрит во вне, второй 10.0.1.0/24 в локальную сеть. Настроен iptables и dnsmasq, все работает. "Под" NAT'ом стоит неуправляемый DGS-1024C.
Есть задача создать vlan'ы для разделения локальной сети.
Что проделано и настроено:
/etc/network/interfaces:
auto lo
iface lo inet loopback

auto enp7s0f0
iface enp7s0f0 inet static
        address 0.0.0.0
        netmask 255.255.255.224
        gateway 0.0.0.0
        dns-nameservers 0.0.0.0

auto enp7s0f1
iface enp7s0f1 inet static
        address 10.0.1.3
        netmask 255.255.255.0
        broadcast 10.0.1.255
        dns-nameservers 10.0.1.2

auto enp7s0f1.2
iface enp7s0f1.2 inet static
        address 10.0.2.1
        netmask 255.255.255.0
        network 10.0.2.0
        broadcast 10.0.2.255
        vlan_raw_device enp7s0f1

post-up /etc/nat


ip a:

3: enp7s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.3/24 brd 10.0.1.255 scope global enp7s0f1
       valid_lft forever preferred_lft forever
4: enp7s0f1.2@enp7s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.1/24 brd 10.0.2.255 scope global enp7s0f1.2
       valid_lft forever preferred_lft forever


Часть iptables по существу:

IF_OUT="enp7s0f0"
LAN1="enp7s0f1"
LAN2="enp7s0f1.2"

$IPT -F
$IPT -F -t nat
$IPT -F -t mangle
$IPT -X
$IPT -t nat -X
$IPT -t mangle -X

$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

$IPT -A INPUT -i ${LAN1} -j ACCEPT
$IPT -A INPUT -i ${LAN2} -j ACCEPT
$IPT -A OUTPUT -o ${LAN1} -j ACCEPT
$IPT -A OUTPUT -o ${LAN2} -j ACCEPT

$IPT -A OUTPUT -o ${IF_OUT} -j ACCEPT
$IPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT


$IPT -A FORWARD -i ${LAN1} -o ${IF_OUT} -s 10.0.1.0/255.255.255.0 -j ACCEPT
$IPT -A FORWARD -i ${IF_OUT} -o ${LAN1} -d 10.0.1.0/255.255.255.0 -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPT -t nat -A POSTROUTING -s 10.0.1.0/255.255.255.0 -j MASQUERADE -o ${IF_OUT}
$IPT -A INPUT -m udp -p udp --dport 53 -s 10.0.1.0/255.255.255.0 -i ${LAN1} -j ACCEPT

# Разрешаем пересылку пакетов из этого влана наружу:
$IPT -A FORWARD -i enp7s0f1.2 -o ${IF_OUT} -s 10.0.2.0/255.255.255.0 -j ACCEPT
$IPT -A FORWARD -i ${IF_OUT} -o enp7s0f1.2 -d 10.0.2.0/255.255.255.0 -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPT -t nat -A POSTROUTING -s 10.0.2.0/255.255.255.0 -j MASQUERADE -o ${IF_OUT}
$IPT -A INPUT -m udp -p udp --dport 53 -s 10.0.2.0/255.255.255.0 -i enp7s0f1.2 -j ACCEPT


ip r на шлюзе:

default via 0.0.0.0 dev enp7s0f0 onlink
10.0.1.0/24 dev enp7s0f1 proto kernel scope link src 10.0.1.3
10.0.2.0/24 dev enp7s0f1.2 proto kernel scope link src 10.0.2.1
0.0.0.0/27 dev enp7s0f0 proto kernel scope link src 0.0.0.0



/proc/net/vlan/config:

VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
enp7s0f1.2     | 2  | enp7s0f1


/proc/net/vlan/enp7s0f1.2:

enp7s0f1.2  VID: 2       REORDER_HDR: 1  dev->priv_flags: 1021
         total frames received            0
          total bytes received            0
      Broadcast/Multicast Rcvd            0

      total frames transmitted          190
       total bytes transmitted         8670
Device: enp7s0f1
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
EGRESS priority mappings:


lsmod | grep 8021q:

8021q                  40960  0
garp                   16384  1 8021q
mrp                    20480  1 8021q


Теперь суть:
На подключенном напрямую к комутатору клиенте (пробовал как debian 8 с RTL8111/8168/8411 так и виртуальную win7 на vbox) сеть не работает, настраивал вручную адрес и шлюз 10.0.2.1.
Пинг не идет ни на шлюз ни куда либо еще, со шлюза клиент тоже не пингутся.
Думал грешным делом, что свитч режет пакеты, пробовал ноутбук подключать на прямую в шлюз, эффекта 0.

Смущает тот факт, что периодически (не всегда), при попытке пинга с клиента на шлюзе tcpdump выдает строки:

tcpdump: listening on enp7s0f1.2, link-type EN10MB (Ethernet), capture size 262144 bytes
18:15:26.059782 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.13 tell 10.0.2.1, length 28

Где зарыта проблема? В настройках iptables или vlan? или вообще на физике интерфейса?

Заранее благодарен за советы/помощь.

endru

Если вы используете VLAN, то клиент, который работает с VLAN сетью должен уметь принимать подобные пакеты и передавать их.
Помимо этого, если в сети есть управляемый коммутатор с поддержкой VLAN, он должен знать на каких портах может быть VLAN трафик.
Иначе ваши пакеты просто гуляют по сети не находят нужного ресурса и глохнут.
Т.е. нужно смотреть tcpdump на сервере и клиенте.

imelya

#2
Цитата: endru от 26 августа 2019, 05:00:30
Если вы используете VLAN, то клиент, который работает с VLAN сетью должен уметь принимать подобные пакеты и передавать их.
Помимо этого, если в сети есть управляемый коммутатор с поддержкой VLAN, он должен знать на каких портах может быть VLAN трафик.
Иначе ваши пакеты просто гуляют по сети не находят нужного ресурса и глохнут.
Т.е. нужно смотреть tcpdump на сервере и клиенте.
Попробовал еще с одной машины, карта  Ethernet Connection I219-V. Модуль подгружен, при ручном назначении адреса из 10.0.2.0 так же ничего не пингуется. Но если адрес в подсети 10.0.1.0 пинг до адреса 10.0.2.1 (адрес шлюза) идет...

tcpdump -vv -ni enp0s31f6| grep 10.0.2.1 на клиенте при адресе из 10.0.1.0:

tcpdump: listening on enp0s31f6, link-type EN10MB (Ethernet), capture size 262144 bytes
    10.0.1.10 > 10.0.2.1: ICMP echo request, id 24289, seq 1, length 64
    10.0.2.1 > 10.0.1.10: ICMP echo reply, id 24289, seq 1, length 64



tcpdump -vv -ni enp0s31f6| grep 10.0.2.1 на клиенте при адресе 10.0.2.0:

tcpdump: listening on enp0s31f6, link-type EN10MB (Ethernet), capture size 262144 bytes
    10.0.2.5 > 10.0.2.1: ICMP echo request, id 24289, seq 1, length 64
    10.0.2.5 > 10.0.2.1: ICMP echo request, id 24289, seq 2, length 64


tcpdump -vv -ni enp7s0f1.2 на сервере:

tcpdump: listening on enp7s0f1.2, link-type EN10MB (Ethernet), capture size 262144 bytes                                                                                                     
08:48:00.011112 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 tell 10.0.1.3, length 28                                                                                       
08:48:01.011567 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 tell 10.0.1.3, length 28                                                                                       
08:48:02.035565 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 tell 10.0.1.3, length 28                                                                                       
08:48:03.977400 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 tell 10.0.1.3, length 28                                                                                       
08:48:04.979565 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.2.5 tell 10.0.2.1, length 28

endru

Цитата: endru от 26 августа 2019, 05:00:30Помимо этого, если в сети есть управляемый коммутатор с поддержкой VLAN, он должен знать на каких портах может быть VLAN трафик.
Иначе ваши пакеты просто гуляют по сети не находят нужного ресурса и глохнут.
перечитывать до наступления просветления.

endru

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

imelya

#5
Цитата: endru от 26 августа 2019, 11:30:46
Схему подключения с таблицей маршрутизации каждого устройства показывай. Полное название всех коммутаторов сюда же.
Плюс настройки клиента для работы с VLAN (какой это клиент - виртуальный, физический).

Коммутатор один, неуправляемый, писал какой в начале: D-Link DGS-1024C.

Таблица на шлюзе:

default via real-ip dev enp7s0f0 onlink
10.0.1.0/24 dev enp7s0f1 proto kernel scope link src 10.0.1.3
10.0.2.0/24 dev enp7s0f1.2 proto kernel scope link src 10.0.2.1
real-gateway/27 dev enp7s0f0 proto kernel scope link src real-ip


Таблица на клиенте 1 (debian 8 с RTL8111/8168/8411):

default via 10.0.2.1 dev eth0  proto static  metric 1024
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.13
169.254.0.0/16 dev eth0  proto static  scope link  metric 1000


Таблица на клиенте 2 (debian 10 с Ethernet Connection I219-V):

default via 10.0.2.1 dev enp0s31f6 proto static metric 100
10.0.2.0/24 dev enp0s31f6 proto kernel scope link src 10.0.2.14 metric 100


Ни на одном ни на втором не работает, если на них настраивать сеть 10.0.1.0/24 - все ок

Схему изобразил. Во вложении. Как и говорил не работает даже подключая клиента на прямую в шлюз, минуя коммутатор. (схема на втором листе вложенного файла)

Клиенты физические. На них никаких настроек на производил. В моем понимании клиенту "по барабану" линк приходит к нему vlan или нет.

endru

#6
Цитата: imelya от 27 августа 2019, 11:05:52Ни на одном ни на втором не работает, если на них настраивать сеть 10.0.1.0/24 - все ок
рука лицо... как ты себе представляешь использование VLAN без настройки клиентов на работу с тегированными (trunk) пакетами?
естественно у тебя не будет работать сеть, пакеты в VLAN2 тупо не попадают.
Эта задача малой кровью не обойдется, либо настраивай VLAN на клиентах, либо покупай управляемый коммутатор и настраивай VLAN там, иначе ничего не получится.

Для подобного метода подключения без настройки клиентов и без нормального коммутатора, тогда нужно настраивать не VLAN а виртуальный (alias) ip адрес. Но тогда ни о какой изоляции сети и речи не идет. И смысла в такой сети я вообще не вижу...

imelya

Цитата: endru от 27 августа 2019, 11:25:17
Цитата: imelya от 27 августа 2019, 11:05:52Ни на одном ни на втором не работает, если на них настраивать сеть 10.0.1.0/24 - все ок
рука лицо... как ты себе представляешь использование VLAN без настройки клиентов на работу с тегированными (trunk) пакетами?
естественно у тебя не будет работать сеть, пакеты в VLAN2 тупо не попадают.
Эта задача малой кровью не обойдется, либо настраивай VLAN на клиентах, либо покупай управляемый коммутатор и настраивай VLAN там, иначе ничего не получится.

Для подобного метода подключения без настройки клиентов и без нормального коммутатора, тогда нужно настраивать не VLAN а виртуальный (alias) ip адрес. Но тогда ни о какой изоляции сети и речи не идет. И смысла в такой сети я вообще не вижу...

"Тупой" коммутатор просто не может правильно направить теггированный пакет...
Конечный клиент должен принимать уже без тега, поэтому не работает даже с напрямую подключенным к шлюзу.
А управляемый коммутатор пришедшие на trunk порт пакеты, как и с тегом так и без, разделяет по правильным портам и отдает клиентам уже без тегов.
Все так?)
На днях поставлю управляемый, буду пробовать.

endru

Обычный коммутатор не смотрит на теги, ему пофиг на них, т.е. он не изолирует среду, а просто шлет пакеты по всем портам коммутатора.
Т.е. если в сети есть обычный коммутатор, то проходя через него пакеты с тегами так и остаются пакетами с тегами.
Допустим порт-1 управляемого коммутатора идет в сервер, значит там должны быть без тега vlan1 и с тегом vlan2.
Далее пусть порт-2 будет клиент обычной сети, его настройки не трограешь.
Порт-3 клиент сети vlan2, этому порту ставишь не тегированный vlan2 (отрубаешь поддержку vlan1).
Как это работает:
коммутатор на 1 порту ожидает что все пакеты без тегов относятся к vlan1 (он по умолчанию всегда), и тегированные vlan2 (сервер настроен все ок тут).
Далее коммутатор смотрит по таблице vlan2 куда нужно отправить пакет этой виртуальной сети, и видит порт 3, и что там клиент не поддерживает теги, он снимает тег vlan2, и отдает сырой пакет сети vlan2.
Тот же процесс происходит наоборот.
коммутатор видит пакет на порт-3, и ставит тег vlan2 на пакет, далее без снятия тега попадет на сервер, и сервер уже сам снимет тег при обработке пакетов.

gardarea51

Прочел по диагонали..
если у вас на сервере настроены vlan'ы, то абоненты в этих виланах могут оказаться только через access-порты.
Access-порт - это порт доступа, в который входит нетегированный трафик и выходит с него также нетегированный трафик,
но сам порт принадлежит к конкретному вилану.

Ну либо сам абонент должен уметь виланы, потому как простые компьютеры в большинстве своем с виланами работать не будут,
сетевая карточка не поддерживает.

Есть еще гибридные, транковые порты.. помимо доступа, у разных вендоров разная терминология.

imelya

#10
Цитата: endru от 28 августа 2019, 04:04:12
Обычный коммутатор не смотрит на теги, ему пофиг на них, т.е. он не изолирует среду, а просто шлет пакеты по всем портам коммутатора.
Т.е. если в сети есть обычный коммутатор, то проходя через него пакеты с тегами так и остаются пакетами с тегами.
Допустим порт-1 управляемого коммутатора идет в сервер, значит там должны быть без тега vlan1 и с тегом vlan2.
Далее пусть порт-2 будет клиент обычной сети, его настройки не трограешь.
Порт-3 клиент сети vlan2, этому порту ставишь не тегированный vlan2 (отрубаешь поддержку vlan1).
Как это работает:
коммутатор на 1 порту ожидает что все пакеты без тегов относятся к vlan1 (он по умолчанию всегда), и тегированные vlan2 (сервер настроен все ок тут).
Далее коммутатор смотрит по таблице vlan2 куда нужно отправить пакет этой виртуальной сети, и видит порт 3, и что там клиент не поддерживает теги, он снимает тег vlan2, и отдает сырой пакет сети vlan2.
Тот же процесс происходит наоборот.
коммутатор видит пакет на порт-3, и ставит тег vlan2 на пакет, далее без снятия тега попадет на сервер, и сервер уже сам снимет тег при обработке пакетов.

Спасибо большое! Ликвидировали часть безграмотности.
Поставил HPE 1820, настроил на нем trunk и vlan, основываюсь на этом. Все работает.