- Вопрос или проблема
- Контекст
- Цель
- Воспроизведение настройки
- Конфигурация WireGuard (выдуманная информация)
- Мост
- Проблема
- Запрос на помощь
- Ответ или решение
- Доступ между интерфейсами в окружении Debian Linux
- Введение
- Сети и интерфейсы
- Причины доступа клиента 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 клиент может успешно выполнять ping ко всем сетевым интерфейсам, включая eth0 и vmbr0.
Видимость пакетов:
При запуске tcpdump на каждом из интерфейсов (eth0, vmbr0 и wg0) наблюдается, что ping-пакеты проходят только через интерфейс wg0. Тем не менее, ответы все еще получаются, когда клиент отправляет ping на другие интерфейсы.
Выявление сервисов:
Если на любом интерфейсе запущен сервис, такой как:
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 клиент все равно может успешно выполнить ping к IP-адресу, связанному с отключенным интерфейсом, и получить доступ к работающему сервису (например, к HTTP серверу). Это поведение сохраняется независимо от состояния работы интерфейса.
Проблема с виртуальной машиной:
При добавлении виртуальной машины на мост vmbr0 VPN клиент не может ее пинговать. (Нормально, но почему я могу пинговать мост)
Запрос на помощь
Учитывая вышеуказанную конфигурацию и наблюдаемые проблемы:
- Почему у VPN клиента есть доступ ко всем интерфейсам (eth0, vmbr0), а не ограничен подсетью и отключенной пересылкой?
- Как VPN клиент все еще может получать доступ к сервисам или пинговать IP-адреса на отключенных интерфейсах?
Будем признательны за любые идеи или решения!
Ответ или решение
Доступ между интерфейсами в окружении Debian Linux
Введение
В вашей инфраструктуре Debian Linux несколько сетевых интерфейсов выполняют разные роли. Ваша цель заключается в том, чтобы ограничить сетевое взаимодействие и обеспечить, чтобы клиент VPN мог обращаться только к определенной виртуальной машине в мосте vmbr0
. Однако, вы столкнулись с рядом проблем, связанными с доступом клиента VPN к разным интерфейсам, включающим eth0
, и описанными аномалиями в поведении сети. Давайте подробно разберем все пункты и попытаемся найти решение.
Сети и интерфейсы
-
Интерфейсы:
eth0
: Публичное подключение (192.0.2.0/24).wg0
: Мы используем WireGuard (10.0.0.0/24).vmbr0
: Мост для виртуальных машин (172.16.0.0/16).
-
Состояние системы:
- Правила брандмауэра не применяются, и все цепочки имеют политику по умолчанию ACCEPT.
- IPv4 переадресация отключена (
net.ipv4.ip_forward = 0
).
Причины доступа клиента VPN ко всем интерфейсам
-
Механизм маршрутизации:
- Хотя у вас отключено переадресация, возможность доступа клиента VPN к интерфейсам по-прежнему открыта, так как пакет отправляется от клиента и проходит через локальный стек сети, который не зависит от глобальных настроек маршрутизации.
-
Отсутствие ограничений доступа:
- Поскольку вы не применяете никаких правил в iptables/nftables, система не блокирует пакеты, передаваемые клиентом к
eth0
иvmbr0
. Это позволяет клиенту VPN свободно взаимодействовать с другими интерфейсами, несмотря на их диапазоны.
- Поскольку вы не применяете никаких правил в iptables/nftables, система не блокирует пакеты, передаваемые клиентом к
Причины доступа к услугам на неработающих интерфейсах
Обращаю внимание, что при отключенном интерфейсе клиент все еще может пинговать IP-адрес и получать доступ к услугам, запущенным на этом интерфейсе. Это может происходить по следующим причинам:
-
Кэширование ARP:
- Ваша система может кэшировать ARP-записи для IP-адресов, при этом запомнив ассоциацию IP-адреса с MAC-адресом до тех пор, пока кэш не обновится. Следовательно, до истечения времени жизни кэша клиент все еще сможет отправлять пакеты на адрес уже имеющегося кэшированного MAC-адреса.
-
Ответы на ловлю (Статические маршруты):
- Возможно, что пакеты, отправленные на IP-адрес неработающего интерфейса, обрабатываются в другом контексте или программном обеспечении, который привязан к этому адресу, что позволяет пользователю VPN по-прежнему видеть и взаимодействовать с этим сервисом.
Решения
Для решения указанных проблем рассмотрим следующие меры:
-
Настройка правил брандмауэра:
- Включите iptables или nftables и настройте соответствующие правила, чтобы разрешить только определенные IP-адреса. Это обеспечит контроль доступа к интерфейсам.
iptables -A FORWARD -i wg0 -o vmbr0 -j ACCEPT iptables -A FORWARD -i wg0 -o eth0 -j DROP iptables -A FORWARD -i wg0 -o wg0 -j DROP
- Включите iptables или nftables и настройте соответствующие правила, чтобы разрешить только определенные IP-адреса. Это обеспечит контроль доступа к интерфейсам.
-
Настройка переадресации:
- Восстановите значение
net.ipv4.ip_forward
в1
, и установите более точные правила маршрутизации.
- Восстановите значение
-
Очистка ARP-кэша:
- Регулярно очищайте кэш ARP (например, с помощью команды
ip -s -s neigh flush all
), что поможет избежать ложной доступности неработающих интерфейсов.
- Регулярно очищайте кэш ARP (например, с помощью команды
-
Изменение конфигурации WireGuard:
- Убедитесь, что
AllowedIPs
в конфигурации WireGuard на клиенте верно ограничивают доступ только к VPN и виртуальным машинам, а не ко всем IP.
- Убедитесь, что
Заключение
Эти шаги помогут вам создать более закрытую и безопасную сетевую архитектуру с четкими правилами доступа. Понимание механизма работы сетевых интерфейсов и актуальных настроек системы даст вам возможность управлять доступом более эффективно и безопасно. Обратите внимание, что поддержка безопасности – это трудоемкий процесс, который требует постоянного контроля и корректировок в соответствии с изменяющимися требованиями и угрозами.