Доступ между интерфейсами

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

Контекст

В моей инфраструктуре Debian Linux я управляю несколькими сетевыми интерфейсами с определенными ролями.

Интерфейс Роль Подсеть Описание
eth0 Общественное подключение 192.0.2.0/24 Используется для внешнего публичного доступа.
wg0 WireGuard VPN 10.0.0.0/24 Обеспечивает безопасное взаимодействие между машинами через VPN.
vmbr0 Мост для Proxmox 172.16.0.0/16 Мост для виртуальных машин.
  • Правила брандмауэра: На данный момент не применяются правила iptables/nftables. Все цепочки имеют политику по умолчанию, установленную на ACCEPT.
  • Конфигурация ядра: Пересылка IPv4 отключена (net.ipv4.ip_forward = 0).

Цель

Цель состоит в том, чтобы строго ограничить сетевое взаимодействие в инфраструктуре:

Когда компьютер подключается к VPN через интерфейс wg0, он должен иметь возможность связываться только с определенной виртуальной машиной, расположенной на мосту vmbr0.

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


Воспроизведение настройки

Конфигурация WireGuard (выдуманная информация)

Чтобы воспроизвести окружение, вот базовая конфигурация WireGuard для двух машин на Linux:

Машина 1: VPN Сервер (выдуманная информация)

Интерфейс: wg0

  1. Генерация ключа (пример ключей, сгенерированных с помощью wg genkey и wg pubkey):

    • Приватный ключ: 9+9N5R5Dje2dmldDtrjQoBb3AFOWhOAyZ9mfWQKn7QY=
    • Публичный ключ: Ci4z9W+n8gfrFRRGZs3DNMHmKk1TFNG9QXGV7zg5OkE=
  2. Конфигурация WireGuard: (выдуманная информация)

    Файл /etc/wireguard/wg0.conf:

    [Interface]
    PrivateKey = 9+9N5R5Dje2dmldDtrjQoBb3AFOWhOAyZ9mfWQKn7QY=
    Address = 10.0.0.1/24
    ListenPort = 51820
    
    [Peer]
    PublicKey = YdC5+zMdKj5cRW2WlAv7GDETx+gjZukOmeC+lkJZ8is=
    AllowedIPs = 10.0.0.2/32
    
  3. Команды для применения:

    sudo wg-quick up wg0
    sudo systemctl enable wg-quick@wg0
    
Машина 2: VPN Клиент (выдуманная информация)

Интерфейс: wg0

  1. Генерация ключа:

    • Приватный ключ: mWjXaRlvJjThhf9ZZpaAWwdY0Puvy0k9fGy7prlzvV8=
    • Публичный ключ: YdC5+zMdKj5cRW2WlAv7GDETx+gjZukOmeC+lkJZ8is=
  2. Конфигурация WireGuard:

    Файл /etc/wireguard/wg0.conf:

    [Interface]
    PrivateKey = mWjXaRlvJjThhf9ZZpaAWwdY0Puvy0k9fGy7prlzvV8=
    Address = 10.0.0.2/24
    
    [Peer]
    PublicKey = Ci4z9W+n8gfrFRRGZs3DNMHmKk1TFNG9QXGV7zg5OkE=
    Endpoint = <SERVER_IP>:51820
    AllowedIPs = 10.0.0.1/24, 172.16.0.0/16, 192.0.2.0/24
    PersistentKeepalive = 25
    
  3. Команды для применения:

    sudo wg-quick up wg0
    sudo systemctl enable wg-quick@wg0
    

Эти конфигурации создают простое соединение между VPN сервером (10.0.0.1) и клиентом (10.0.0.2). Эта настройка является основой для тестирования описанного требования.

Мост

sudo brctl addbr vmbr0
sudo ip addr add 172.16.0.1/16 dev vmbr0
sudo ip link set dev vmbr0 up

Проблема

Когда клиент подключается к VPN через интерфейс wg0, наблюдаются следующие проблемы:

Доступ ко всем интерфейсам:
Несмотря на разные подсети и отключенную пересылку IPv4, VPN клиент может успешно выполнять ping ко всем сетевым интерфейсам, включая eth0 и vmbr0.

Видимость пакетов:
При запуске tcpdump на каждом из интерфейсов (eth0, vmbr0 и wg0) наблюдается, что ping-пакеты проходят только через интерфейс wg0. Тем не менее, ответы все еще получаются, когда клиент отправляет ping на другие интерфейсы.

Выявление сервисов:
Если на любом интерфейсе запущен сервис, такой как:

python3 -m http.server --bind 192.0.2.1

(привязан к IP-адресу eth0 192.0.2.1/24), VPN клиент получает доступ к этому сервису.

Сценарий отключения интерфейса:
Если интерфейс (например, eth0) отключен с помощью:

ip link set dev eth0 down

VPN клиент все равно может успешно выполнить ping к IP-адресу, связанному с отключенным интерфейсом, и получить доступ к работающему сервису (например, к HTTP серверу). Это поведение сохраняется независимо от состояния работы интерфейса.

Проблема с виртуальной машиной:
При добавлении виртуальной машины на мост vmbr0 VPN клиент не может ее пинговать. (Нормально, но почему я могу пинговать мост)

Запрос на помощь

Учитывая вышеуказанную конфигурацию и наблюдаемые проблемы:

  • Почему у VPN клиента есть доступ ко всем интерфейсам (eth0, vmbr0), а не ограничен подсетью и отключенной пересылкой?
  • Как VPN клиент все еще может получать доступ к сервисам или пинговать IP-адреса на отключенных интерфейсах?

Будем признательны за любые идеи или решения!

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

Доступ между интерфейсами в окружении Debian Linux

Введение

В вашей инфраструктуре Debian Linux несколько сетевых интерфейсов выполняют разные роли. Ваша цель заключается в том, чтобы ограничить сетевое взаимодействие и обеспечить, чтобы клиент VPN мог обращаться только к определенной виртуальной машине в мосте vmbr0. Однако, вы столкнулись с рядом проблем, связанными с доступом клиента VPN к разным интерфейсам, включающим eth0, и описанными аномалиями в поведении сети. Давайте подробно разберем все пункты и попытаемся найти решение.

Сети и интерфейсы

  1. Интерфейсы:

    • eth0: Публичное подключение (192.0.2.0/24).
    • wg0: Мы используем WireGuard (10.0.0.0/24).
    • vmbr0: Мост для виртуальных машин (172.16.0.0/16).
  2. Состояние системы:

    • Правила брандмауэра не применяются, и все цепочки имеют политику по умолчанию ACCEPT.
    • IPv4 переадресация отключена (net.ipv4.ip_forward = 0).

Причины доступа клиента VPN ко всем интерфейсам

  1. Механизм маршрутизации:

    • Хотя у вас отключено переадресация, возможность доступа клиента VPN к интерфейсам по-прежнему открыта, так как пакет отправляется от клиента и проходит через локальный стек сети, который не зависит от глобальных настроек маршрутизации.
  2. Отсутствие ограничений доступа:

    • Поскольку вы не применяете никаких правил в iptables/nftables, система не блокирует пакеты, передаваемые клиентом к eth0 и vmbr0. Это позволяет клиенту VPN свободно взаимодействовать с другими интерфейсами, несмотря на их диапазоны.

Причины доступа к услугам на неработающих интерфейсах

Обращаю внимание, что при отключенном интерфейсе клиент все еще может пинговать IP-адрес и получать доступ к услугам, запущенным на этом интерфейсе. Это может происходить по следующим причинам:

  1. Кэширование ARP:

    • Ваша система может кэшировать ARP-записи для IP-адресов, при этом запомнив ассоциацию IP-адреса с MAC-адресом до тех пор, пока кэш не обновится. Следовательно, до истечения времени жизни кэша клиент все еще сможет отправлять пакеты на адрес уже имеющегося кэшированного MAC-адреса.
  2. Ответы на ловлю (Статические маршруты):

    • Возможно, что пакеты, отправленные на IP-адрес неработающего интерфейса, обрабатываются в другом контексте или программном обеспечении, который привязан к этому адресу, что позволяет пользователю VPN по-прежнему видеть и взаимодействовать с этим сервисом.

Решения

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

  1. Настройка правил брандмауэра:

    • Включите iptables или nftables и настройте соответствующие правила, чтобы разрешить только определенные IP-адреса. Это обеспечит контроль доступа к интерфейсам.
      iptables -A FORWARD -i wg0 -o vmbr0 -j ACCEPT
      iptables -A FORWARD -i wg0 -o eth0 -j DROP
      iptables -A FORWARD -i wg0 -o wg0 -j DROP
  2. Настройка переадресации:

    • Восстановите значение net.ipv4.ip_forward в 1, и установите более точные правила маршрутизации.
  3. Очистка ARP-кэша:

    • Регулярно очищайте кэш ARP (например, с помощью команды ip -s -s neigh flush all), что поможет избежать ложной доступности неработающих интерфейсов.
  4. Изменение конфигурации WireGuard:

    • Убедитесь, что AllowedIPs в конфигурации WireGuard на клиенте верно ограничивают доступ только к VPN и виртуальным машинам, а не ко всем IP.

Заключение

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

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

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