VLAN поверх OpenVPN: нужна помощь!

Вопрос или проблема

Я пишу, потому что испытываю трудности с настройкой инфраструктуры с использованием pfSense и OpenVPN, и уже несколько дней безуспешно пытаюсь понять, что делаю не так.

Сценарий использования, который я хочу реализовать, заключается в подключении облачных серверов к существующей инфраструктуре, которая имеет периферийные фаерволы pfSense и предоставляет сервер OpenVPN.

Однако я не хочу использовать маршрутизацию; вместо этого я хочу создать туннель tap для передачи тегированных VLAN через него.

На сервере я включил тегирование VLAN в соответствии с документацией OpenVPN (https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html), создав туннель tap и включив –vlan-tagging. Мне не нужны нетегированные пакеты.

На pfSense я создал две VLAN на интерфейсе OpenVPN:

Созданные VLAN над интерфейсом сервера OpenVPN

Затем я создал два моста между VLAN и физическими интерфейсами на фаерволе (которые отмечены на гипервизоре Proxmox, где работает pfSense):

Созданные мосты на pfSense

Статус интерфейса на pfSense следующий:

Статус физических интерфейсов (отмеченных на Proxmox)

Статус VLAN на интерфейсе OpenVPN

На клиенте (другой сервер Proxmox) я создал следующие мосты на интерфейсе tap0, открытом клиентом OpenVPN:

root@node1:~# ip link
[...]
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 10:7c:61:4c:4e:64 brd ff:ff:ff:ff:ff:ff
12: tap99101i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 56:d9:73:5e:9d:fb brd ff:ff:ff:ff:ff:ff
29: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 6a:6b:26:c3:ea:c5 brd ff:ff:ff:ff:ff:ff
30: tap0.150@tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr150 state UP mode DEFAULT group default qlen 1000
    link/ether 6a:6b:26:c3:ea:c5 brd ff:ff:ff:ff:ff:ff
31: vmbr150: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 6a:6b:26:c3:ea:c5 brd ff:ff:ff:ff:ff:ff
32: tap0.151@tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr151 state UP mode DEFAULT group default qlen 1000
    link/ether 6a:6b:26:c3:ea:c5 brd ff:ff:ff:ff:ff:ff
33: vmbr151: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 6a:6b:26:c3:ea:c5 brd ff:ff:ff:ff:ff:ff

root@node1:~# brctl show
bridge name bridge id       STP enabled interfaces
vmbr0       8000.107c614c4e64   no      enp5s0
vmbr150     8000.6a6b26c3eac5   no      tap0.150
vmbr151     8000.6a6b26c3eac5   no      tap0.151

Мост vmbr150 правильно имеет IP-адрес, который относится к той же сети, что и физические интерфейсы pfSense (а vmbr151 не имеет IP-адреса, так как он предназначен для виртуальных машин, работающих на удаленном Proxmox):

root@node1:~# ip addr
[...]
30: tap0.150@tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr150 state UP group default qlen 1000
    link/ether 6a:6b:26:c3:ea:c5 brd ff:ff:ff:ff:ff:ff
31: vmbr150: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 6a:6b:26:c3:ea:c5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.150.1/24 scope global vmbr150
       valid_lft forever preferred_lft forever
    inet6 fe80::686b:26ff:fec3:eac5/64 scope link
       valid_lft forever preferred_lft forever
32: tap0.151@tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr151 state UP group default qlen 1000
    link/ether 6a:6b:26:c3:ea:c5 brd ff:ff:ff:ff:ff:ff
33: vmbr151: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 6a:6b:26:c3:ea:c5 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::686b:26ff:fec3:eac5/64 scope link
       valid_lft forever preferred_lft forever

Ссылка установлена, и я не вижу никаких ошибок конфигурации, но несмотря на это, простой ping не достигает другой стороны (на pfSense пока нет правил фаервола, разрешающих трафик, но я даже не вижу пакетов, покидающих удаленный Proxmox):

root@node1:~# ping 192.168.150.251
PING 192.168.150.251 (192.168.150.251) 56(84) байт данных.
From 192.168.150.1 icmp_seq=1 Destination Host Unreachable
From 192.168.150.1 icmp_seq=2 Destination Host Unreachable
From 192.168.150.1 icmp_seq=3 Destination Host Unreachable
From 192.168.150.1 icmp_seq=4 Destination Host Unreachable

`tcpdump` показывает только ARP-запросы, что наводит меня на мысль, что пакеты даже не покидают соединение OpenVPN:

root@node1:~# tcpdump -i tap0.150
tcpdump: подробный вывод подавлен, используйте -v[v]... для полного декодирования протокола
прослушивание на tap0.150, тип канала EN10MB (Ethernet), длина снимка 262144 байт
14:10:39.220037 ARP, Request who-has 192.168.150.251 tell 192.168.150.1, длина 28
14:10:40.244045 ARP, Request who-has 192.168.150.251 tell 192.168.150.1, длина 28
14:10:41.268019 ARP, Request who-has 192.168.150.251 tell 192.168.150.1, длина 28
14:10:42.292068 ARP, Request who-has 192.168.150.251 tell 192.168.150.1, длина 28
14:10:43.315991 ARP, Request who-has 192.168.150.251 tell 192.168.150.1, длина 28

Кто-нибудь может помочь мне понять, что я делаю не так?

Большое спасибо!

Ответ или решение

Конфигурация вашей сети, использующей pfSense и OpenVPN для передачи тегированных VLAN через туннель tap, представляется сложной задачей, которая требует четкого понимания различных сетевых компонентов и их взаимодействия. Давайте разберем теорию, ваши примеры и то, как можно применять решения на практике.

Теория

  1. VLAN через туннель OpenVPN с использованием интерфейсов tap:

    • OpenVPN предоставляет два типа интерфейсов для настройки: tun и tap. В то время как tun используется для маршрутизации IP трафика между клиентами и сервером, tap выполняет роль мостов и позволяет передавать Ethernet-кадры, что делает возможным поддержку VLAN, если на обоих концах туннеля используется vlan-тегирование.
    • Для работы VLAN через OpenVPN необходимо убедиться, что трафик между tap-интерфейсами на сервере и клиенте корректно обрабатывается и маршрутизируется.
  2. pfSense и настройки VLAN:

    • pfSense поддерживает создание VLAN на интерфейсах. При создании VLAN на интерфейсе OpenVPN важно правильно настроить тегирование и убедиться, что все виртуальные мосты, мосты и физические интерфейсы взаимодействуют правильно.
    • Также стоит проверить правила брандмауэра в pfSense. Даже если вы уверены, что трафик должен проходить без проблем, любые заблокированные пакеты или неправильные правила могут вызвать проблемы.
  3. Роль Proxmox в вашей конфигурации:

    • Поскольку Proxmox выполняет роль гипервизора, который управляет виртуальными машинами и сетевыми интерфейсами, важно, чтобы интерфейсы на уровне гипервизора тоже были правильно сконфигурированы, обеспечивая правильное прохождение тегированных пакетов между сетями.

Примеры

В вашем описании вы используете pfSense для создания VLAN и мостов, как на сервере, так и на клиенте, при этом настройки интерфейсов и их конфигурации выглядят следующим образом:

  • На стороне pfSense:

    • Вы создали два VLAN на интерфейсе OpenVPN и правильно связали их с физическими интерфейсами с помощью мостов. Важно удостовериться, что эти физические интерфейсы и мосты получают правильный трафик.
    • Убедитесь, что интерфейсы, используемые для бриджинга, работают как надо и правильно настроены на уровне гипервизора Proxmox.
  • На стороне клиента (Proxmox сервер):

    • Вы настроили узлы Linux с мостами, связанными с tap-интерфейсами OpenVPN и их VLAN. Убедитесь, что IP-адреса и маршрутизация здесь корректны.
    • Ваша команда tcpdump показывает, что ARP-запросы отправляются, но не получают отклика. Это может означать, что трафик не выходит за пределы вашей локальной конфигурации, и он может блокироваться или не маршрутизироваться верно.

Применение

Для решения вашей проблемы попробуйте следующие действия:

  1. Проверка конфигурации OpenVPN:

    • Убедитесь, что конфигурация OpenVPN как на сервере, так и на клиенте поддерживает tap и VLAN-тегирование. Проверьте, что все используемые опции –vlan-tagging и связанные опции включены.
    • Проверьте логи OpenVPN на наличие ошибок подключения или конфигурации.
  2. Проверка сетевых маршрутов:

    • Убедитесь, что все маршруты между вашими сетями корректны. Проверьте и скорректируйте таблицы маршрутизации по необходимости.
    • На стороне клиента выполните traceroute (или tracert на Windows) к удаленному IP, чтобы увидеть, где может останавливаться пакет.
  3. Проверка правил брандмауэра pfSense:

    • Создайте временное правило, разрешающее весь трафик через интерфейсы OpenVPN и VLAN, чтобы убедиться, что проблема не в блокировке трафика. В случае необходимости подкорректируйте правила.
  4. Тестирование и отладка с использованием инструментов TCP/IP:

    • Используйте инструменты, такие как ping с увеличенным таймаутом или sniffer, чтобы посмотреть, проходят ли пакеты через туннель OpenVPN.
    • Настройте логирование на всех интерфейсах VLAN и мостах, чтобы видеть, какой трафик проходит и где могут возникать блокировки.

Эти шаги должны помочь выявить и устранить неполадки в вашей конфигурации. Убедитесь, что все компоненты от клиента до сервера правильно видят и обрабатывают трафик. Надеюсь, это руководство поможет вам успешно реализовать вашу сетевую инфраструктуру.

Оцените материал
Добавить комментарий

Капча загружается...