- Вопрос или проблема
- Цель
- Воспроизведение настройки
- Конфигурация WireGuard (фейковые данные)
- Мост
- Проблема
- Запрос о помощи
- Ответ или решение
- Почему VPN-клиент имеет доступ ко всем интерфейсам, а не ограничивается подсетью и параметром отключения пересылки?
- 1. Конфигурация WireGuard
- 2. Отключение пересылки IP
- 3. Проблема обращения к "выключенным" интерфейсам
- 4. Пингование виртуальной машины на bridge-интерфейсе
- Рекомендации по ограничению доступа 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
-
Генерация ключей (пример ключей, сгенерированных с помощью
wg genkeyиwg pubkey):- Приватный ключ:
9+9N5R5Dje2dmldDtrjQoBb3AFOWhOAyZ9mfWQKn7QY= - Публичный ключ:
Ci4z9W+n8gfrFRRGZs3DNMHmKk1TFNG9QXGV7zg5OkE=
- Приватный ключ:
-
Конфигурация 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 -
Команды для применения:
sudo wg-quick up wg0 sudo systemctl enable wg-quick@wg0
Машина 2: VPN клиент (фейковые данные)
Интерфейс: wg0
-
Генерация ключей:
- Приватный ключ:
mWjXaRlvJjThhf9ZZpaAWwdY0Puvy0k9fGy7prlzvV8= - Публичный ключ:
YdC5+zMdKj5cRW2WlAv7GDETx+gjZukOmeC+lkJZ8is=
- Приватный ключ:
-
Конфигурация 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 -
Команды для применения:
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-клиента к другим интерфейсам, крайне важно:
-
Изменить настройки AllowedIPs: Заменить строку
AllowedIPsна одну подсеть, которая соответствует только виртуальной машине, например:AllowedIPs = 10.0.0.1/32 # Только VPN-сервер -
Внедрить правила фаервола: Используйте iptables или nftables для ограничения трафика. Например, может понадобиться прописать правила, запрещающие доступ к IP-адресам других интерфейсов.
-
Убедиться в учете состояния интерфейсов: Следите за состоянием интерфейсов и корректно обрабатывайте ситуации, когда интерфейсы должны быть отключены.
-
Настроить политику маршрутизации: Убедитесь, что маршрутизация настроена так, чтобы клиент VPN не имел доступа к нежелательным интерфейсам.
Применяя указанные рекомендации, вы сможете значительно улучшить изоляцию сетей и предотвратить нежелательный доступ через VPN.