- Вопрос или проблема
- Цель
- Воспроизведение конфигурации
- Конфигурация WireGuard (фальшивая информация)
- Мост
- Проблема
- Запрос на помощь
- Ответ или решение
- Вопрос: Почему клиент VPN имеет доступ ко всем интерфейсам (eth0, vmbr0), несмотря на ограничения по подсетям и отключение пересылки?
- 1. Параметры конфигурации
- 2. Причины доступа к другим интерфейсам
- 3. Почему клиент VPN может пинговать "выключенные" интерфейсы?
- 4. Ограничение доступа клиента 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 имеет доступ ко всем интерфейсам (eth0, vmbr0), несмотря на ограничения по подсетям и отключение пересылки?
В процессе настройки безопасной сети с использованием VPN у вас возникли трудности с ограничением доступа клиентов VPN только к нужным сетевым интерфейсам. Давайте внимательно рассмотрим вашу конфигурацию и выявим причины текущего поведения.
1. Параметры конфигурации
Вы указали, что ваш сервер использует следующие сетевые интерфейсы:
- eth0: Публичное соединение (192.0.2.0/24)
- wg0: Интерфейс WireGuard VPN (10.0.0.0/24)
- vmbr0: Мост для Proxmox (172.16.0.0/16)
При этом отсутствуют правила iptables/nftables, а политика по умолчанию установлена на ACCEPT. Важно отметить, что IPv4 пересылка отключена (net.ipv4.ip_forward = 0).
2. Причины доступа к другим интерфейсам
Несмотря на вашу конфигурацию, клиент VPN имеет возможность взаимодействовать с другими интерфейсами по следующим причинам:
-
Отсутствие правил фильтрации: Поскольку вы не используете iptables или nftables для фильтрации трафика, весь входящий и исходящий трафик принимается без исключений. Поэтому, даже если пересылка отключена, без правил фильтрации запрещены не будут.
-
AllowedIPs и маршрутизация: В конфигурации клиента указаны следующие AllowedIPs:
10.0.0.1/24, 172.16.0.0/16, 192.0.2.0/24
. Это позволяет клиенту не только получать доступ к VPN, но и к подсетям, которые указаны в AllowedIPs. Ваша подсеть 192.0.2.0/24 включает интерфейс eth0, что и обуславливает возможность пинга этого интерфейса. -
Обработка ответов: Даже если интерфейс eth0 выключен, служба, запущенная на этом интерфейсе, может продолжать получать запросы, если сеть (в частности, bridge vmbr0) еще активна. Это может объяснить возможность получать доступ к HTTP-серверу, запущенному на eth0.
3. Почему клиент VPN может пинговать "выключенные" интерфейсы?
Когда вы отключаете интерфейс (например, с помощью команды ip link set dev eth0 down
), IP-адреса, связанные с этим интерфейсом, остаются в системной таблице маршрутов. Это означает, что, с точки зрения TCP/IP стека, адрес все еще доступен, пока не будет изменено значение маршрутов. Таким образом, клиент может продолжать отправлять запросы на этот адрес, хотя фактически он не подключен.
4. Ограничение доступа клиента VPN
Для достижения цели – ограничения доступа к определенным интерфейсам – необходимо внести изменения в конфигурацию:
-
Активируйте фильтрацию трафика: Добавьте правила iptables или nftables, которые будут блокировать нежелаемый трафик с интерфейсов. Например, вы можете настроить iptables так, чтобы он разрешал доступ только к конкретному IP-серверам на интерфейсе vmbr0.
-
Отредактируйте AllowedIPs: Сократите диапазон в настройках AllowedIPs на стороне клиента, например, до
10.0.0.1/24, 172.16.0.0/16
, исключив 192.0.2.0/24. Это уменьшит доступ к интерфейсам eth0. -
Мониторинг и логирование: Настройка логирования в iptables может помочь отслеживать нежелательный трафик, что даст вам понимание, какая коммуникация происходит между интерфейсами.
Заключение
Необходимо рассмотреть проблемы с доступом к другим интерфейсам как следствие конфигурации, которая не выполняет обязательные условия безопасности. Настройка правил фильтрации и корректное управление сетевыми маршрутами — ключ к обеспечению безопасности вашей инфраструктуры. Имея это в виду, вы сможете создать более остоятельный и безопасный контроль доступа для клиентов VPN в вашей системе.