Почему VPN-клиент имеет доступ ко всем интерфейсам вместо того, чтобы быть ограниченным подсетью и отключенной функцией пересылки?

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

В моей инфраструктуре 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 успешно пингует все сетевые интерфейсы, включая eth0 и vmbr0.

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

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

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 по-прежнему может успешно пинговать IP-адрес, связанный с отключенным интерфейсом, и получать доступ к запущенному сервису (например, HTTP серверу). Это поведение сохраняется независимо от рабочего состояния интерфейса.

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

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

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

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

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

Почему клиент VPN имеет доступ ко всем интерфейсам, вместо того чтобы быть ограниченным подсетями и отключенной переадресацией?

Введение

Виртуальные частные сети (VPN) стали важным инструментом для обеспечения безопасности и конфиденциальности сетевых соединений. Однако, как вы отметили в своей инфраструктуре на базе Debian Linux, у клиента VPN есть доступ ко всем сетевым интерфейсам, что вызывает некоторые опасения. Давайте детально рассмотрим возможные причины этой ситуации.

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

  1. Конфигурация WireGuard:

    • Ваша конфигурация WireGuard для клиента включает в себя строки AllowedIPs = 10.0.0.1/24, 172.16.0.0/16, 192.0.2.0/24. Это позволяет клиенту маршрутизировать трафик не только для адреса VPN, но и для других подсетей. Даже если у вас отключена переадресация (значение net.ipv4.ip_forward = 0), записи в таблице маршрутизации продолжают действовать. Это может привести к тому, что клиент будет иметь доступ к трафику, относящемуся ко всем упомянутым интерфейсам.
  2. Отсутствие правил брандмауэра:

    • Указание на то, что в конфигурации iptables или nftables нет активных правил, приводит к тому, что все цепочки имеют значение ACCEPT по умолчанию. Это означает, что любые входящие пакеты, включая ответы, не будут блокироваться, и клиент может взаимодействовать с любыми доступными интерфейсами.
  3. Проблема с пингом и согласованием маршрутов:

    • Когда клиент VPN отправляет ICMP-эхо-запрос на другие интерфейсы, маршрутизация трафика происходит внутри вашего VPN-сервера. Поскольку пинг проходит через интерфейс wg0, а ответы могут направляться обратно напрямую на клиент, вы видите успешные результаты. Поскольку маршрутизатор (ваш VPN-сервер) знает, что запрос был отправлен от клиента на IP, находящиеся в других подсетях, он может направить ответ в соответствии с конфигурацией сети.
  4. Состояние интерфейсов:

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

Как решить проблему ограничения доступа?

  1. Уточните конфигурацию WireGuard:

    • Измените строку AllowedIPs клиента на более ограниченные значения, например, только на IP виртуальной машины, с которой вы хотите обеспечить доступ, исключив другие подсети.
  2. Настройка брандмауэра:

    • Настройте правила iptables или nftables, чтобы ограничить доступ к другим интерфейсам. Например, можно запретить входящий трафик с IP-адресов, которые не относятся к определенным интерфейсам или подсетям.
  3. Проверка маршрутизации:

    • Проверьте таблицу маршрутизации и убедитесь, что маршруты правильно настроены и не позволяют исходящему трафику в ненужные подсети.
  4. Использование более строгих политик безопасности:

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

Заключение

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

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

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