(РЕШЕНО) Почему клиент 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-клиент получает доступ ко всем сетевым интерфейсам. Это поведение имеет несколько ключевых причин, которые следует рассмотреть.

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

Ваше конфигурирование WireGuard на клиенте задаёт следующие параметры:

AllowedIPs = 10.0.0.1/24, 172.16.0.0/16, 192.0.2.0/24

Эта строка указывает, что клиент может направлять трафик к этим подсетям через VPN. При этом он получает доступ не только к заданной ему внутренней сети (10.0.0.0/24), но и к другим указанным подсетям. Таким образом, все запросы на адреса из этих подсетей (включая интерфейсы eth0 и vmbr0) будут допустимы, что объясняет доступ клиента ко всем интерфейсам.

2. Отключение пересылки IP

Хотя вы указали net.ipv4.ip_forward = 0, это лишь предотвращает пересылку пакетов между интерфейсами на сервере. Это не влияет на возможность клиента инициировать соединения. Как только клиент из своей сети (10.0.0.2) посылает запрос к IP-адресу другим интерфейсам, этот пакет попадает на сервер, где он обрабатывается отдельно.

3. Проблема обращения к "выключенным" интерфейсам

Такое поведение может быть связано с тем, что сетевые стеки Linux имеют возможность демонстрировать IP-адреса, которые были заданы интерфейсам, даже если интерфейсы отключены. Это связано с тем, что вывод Ping определяется тем, что пакет отправляется на уровень IP, и, если адрес доступен, ответ может быть возвращён от стека. На самом деле, системный стек просто не знает о состоянии физического интерфейса и будет отвечать, как будто он активен, пока со стороны программы (например, tcpdump) он будет фиксировать пакеты.

4. Пингование виртуальной машины на bridge-интерфейсе

Когда клиент не может пинговать виртуальную машину на интерфейсе vmbr0, это может быть связано с тем, что NAT или маршрутизация на вашей машине настроены так, что пакеты от VPN-клиента не доходят до виртуальной машины. Однако пинг на сам bridge-интерфейс возможен, так как это не влияет на состояние виртуальной машины и просто расценивается как пинг в пределах локальной сети.

Рекомендации по ограничению доступа VPN-клиента

Чтобы ограничить доступ VPN-клиента к другим интерфейсам, крайне важно:

  1. Изменить настройки AllowedIPs: Заменить строку AllowedIPs на одну подсеть, которая соответствует только виртуальной машине, например:

    AllowedIPs = 10.0.0.1/32  # Только VPN-сервер
  2. Внедрить правила фаервола: Используйте iptables или nftables для ограничения трафика. Например, может понадобиться прописать правила, запрещающие доступ к IP-адресам других интерфейсов.

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

  4. Настроить политику маршрутизации: Убедитесь, что маршрутизация настроена так, чтобы клиент VPN не имел доступа к нежелательным интерфейсам.

Применяя указанные рекомендации, вы сможете значительно улучшить изоляцию сетей и предотвратить нежелательный доступ через VPN.

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

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