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

Контекст

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

• Правила брандмауэра: В настоящее время не применяются правила 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) наблюдается, что пакеты пинга проходят только через интерфейс 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-клиент имеет доступ ко всем интерфейсам (eth0, vmbr0), вместо того чтобы быть ограниченным по подсети и отключенной опции перенаправления?

Вы как бы сами на это ответили 🙂

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

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

Почему?

ip rule (man 8 ip-rule) покажет, что local таблица маршрутизации используется первой для обработки пакета, поскольку она имеет наименьший приоритет (0).

Из man 8 ip-route:

local – назначения назначены этому хосту. Пакеты отправляются обратно и доставляются локально.

Этот ответ (https://unix.stackexchange.com/a/524304/651211) также объясняет это и предлагает решение для предотвращения такого поведения.

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

Это зависит от того, как IPv4-адрес назначен системе (и настроен на отключенном интерфейсе). Для статической адресации IPv4-адрес все еще настроен на интерфейсе. Просто выполните быструю ip addr show или ip route show table local и убедитесь сами, что адрес все еще должен быть указан и маршрутизироваться локально.
Для IPv6 вы решаете, что делать. По умолчанию адрес удаляется (см. параметр ядра keep_addr_on_down для /proc/sys/net/ipv6/)