Во-первых, я знаю, что подобные вопросы задавались в другом месте (я прочитал многие из этих сообщений!), но я не смог найти решение своей проблемы, поэтому я прошу помощи.
Моя установка
В моей локальной сети есть две сети: 192.168.0.0/24 и 10.11.12.0/24. Первый имеет DHCP, работающий на моем маршрутизаторе WAN, второй запускает dnsmasq на Ubuntu Server 20.04 на компьютере, который также служит маршрутизатором между двумя подсетями. Я настроил dnsmasq для обслуживания DHCP только в сети 10.11.12.0/24 с параметром no-dhcp-interface=wlp3s0, где wlp3s0 является интерфейсом на стороне 192.168.0.0/24.
Обобщить:
Маршрутизатор WAN (шлюз в WAN) — 192.168.0.1/24.
Запускает DHCP для клиентов на 192.168.0.0/24
Роутер (ч/б подсети):
Ubuntu Server 20.04 с двумя интерфейсами
wlp3s0: 192.168.0.2/24 (статический IP-адрес)
eno1: 10.11.12.1/24 (статический IP)
Я настроил iptables на FWD и NAT вот так.
iptables -t nat -A POSTROUTING -o wlp3s0 -j MASQUERADE
iptables -A FORWARD -i wlp3s0 -o eno1 -m состояние --state СВЯЗАННО, УСТАНОВЛЕНО -j ПРИНЯТЬ
iptables -A ВПЕРЕД -i eno1 -o wlp3s0 -j ПРИНЯТЬ
Я разрешил DHCP через свой брандмауэр с помощью ufw разрешить 67/udp:
К действию от
-- ------ ----
67/udp РАЗРЕШИТЬ ВХОД ВСЕГДА
Кажется, все работает нормально. Однако по опыту я знаю, что запуск двух таких DHCP-серверов может вызвать конфликты, если они не строго разделены. (Клиенты, предназначенные для сети 192.168.0.0/24, не были бы слишком довольны, если бы DHCP предоставил им IP-адрес в сети 10.11.12.0/24!)
Обнаружение проблемы
Поэтому я сделал следующее, чтобы проверить это.Я настроил прослушивание tcpdump на интерфейсе wlp3s0 (192.168.0.2) и использовал nmap для имитации запроса DHCP Discover, исходящего от интерфейса eno1 (10.11.12.1/24), например так:
sudo tcpdump -i wlp3s0 -n порт udp 67 или порт 68
sudo nmap --script трансляция-dhcp-discover -e eno1
Как и ожидалось, я получаю предложение DHCP от dnsmasq, работающего на 10.11.12.1. Все идет нормально!
Некоторые детали для краткости опущены в выводе (он сказал)
Начиная с Nmap 7.80 ( https://nmap.org ) 22 декабря 2021 г. в 16:19 UTC
Результаты предварительного сканирования скрипта:
| широковещательный DHCP-обнаружение:
| Ответ 1 из 1:
| Предлагаемый IP: 10.11.12.53
| Тип сообщения DHCP: DHCPOFFER
| Идентификатор сервера: 10.11.12.1
| Адрес трансляции: 10.11.12.255
| Маска подсети: 255.255.255.0
| Сервер доменных имен: 10.11.12.1
|_ Маршрутизатор: 10.11.12.1
Однако tcpdump показывает, что оба DHCP-сервера отвечают на запрос обнаружения. (На самом деле, мой WAN-маршрутизатор отправляет 2 ответа!)
16:19:43.517029 IP 10.11.12.1.68 > 255.255.255.255.67: BOOTP/DHCP, запрос от de:ad:c0:de:ca:fe, длина 316
16:19:46.486227 IP 10.11.12.1.67 > 255.255.255.255.68: BOOTP/DHCP, ответ, длина 321
16:19:46.794207 IP 192.168.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, ответ, длина 323
16:19:46.794207 IP 192.168.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, ответ, длина 323
Похоже, что запрос на обнаружение DHCP перенаправляется в сеть 192.168.0.0/24 через интерфейс wlp3s0. Глядя на мои правила iptables и брандмауэра, я не вижу причин этому удивляться. Однако то, с чем я действительно борюсь, - это выяснить, как это предотвратить.
Что я пробовал
Я пробовал различные перестановки правил как в ufw, так и в iptables, но безрезультатно, вероятно, потому, что я не полностью понимаю ни iptables, ни ufw. Несколько примеров того, что я пробовал:
(Все правила ufw/iptables были добавлены вверху соответствующего набора/цепочки правил, чтобы обеспечить их выполнение.)
уфв:
# Ограничить 67/udp одним интерфейсом
ufw разрешить вход на eno1 proto udp с 0.0.0.0/0 на 0.0.0.0/0 порт 67
# Запретить маршрутизацию
ufw route deny in on eno1 out on wlp3s0 to 0.0.0.0/0 port 67 proto udp
IP-таблицы:
# Запретить переадресацию UDP-порта 67/68
iptables -I FORWARD 1 -p udp --match multiport --dports 67,68 -j DROP
# Отключить исходящий порт UDP 67
iptables -I ВЫВОД 1 -p udp --match multiport --dports 67,68 -o wlp3s0 -j DROP
Мне, должно быть, не хватает фундаментального понимания того, как это работает, поскольку ничто из вышеперечисленного не мешает DHCP-маршрутизатору WAN получать обнаружение и предлагать IP-адрес в подсети 192.168.0.0/24.
Я где-то читал, что DHCP-серверы могут прослушивать необработанный (или пакетный?) сокет, который не подчиняется iptables. Это не относится к dnsmasq, как описано здесь. https://github.com/imp/dnsmasq/blob/master/FAQ#L195. Я также доказал это, удалив правило allow 67/udp в ufw, после чего dnsmasq перестает отвечать на обнаружение DHCP. Возможно, это удивительно (или нет), но даже с удалением правила разрешения в ufw мой маршрутизатор WAN продолжает получать и отвечать на обнаружение DHCP. Предположительно, потому что у меня есть правила iptables, настроенные для пересылки всего трафика, но нет эквивалентного правила INPUT (пока я не добавлю его с помощью ufw).
Чего я хотел бы достичь
Предпочтительно, я бы хотел, чтобы широковещательная рассылка DHCP в сети 10.11.12.0/24 не достигала даже сети 192.168.0.0/24.
Если это окажется трудным, я был бы рад просто предотвратить доступ предложений DHCP от моего WAN-маршрутизатора к сети 10.11.12.0/24.
Обратите внимание, что у меня нет проблем с сетью 192.168.0.0/24, поскольку я настроил dnsmasq так, чтобы он не предлагал DHCP на интерфейсе wlp3s0 (192.168.0.2). Похоже, это работает, и DHCP обнаруживает на wlp3s0 (192.168.0.2/24) не получает ответа от dnsmasq.
Итак, что мне не хватает? Я делаю это совершенно неправильно или я просто не совсем правильно понимаю? Буду признателен за любую оказанную помощь.
Счастливых праздников!
Обновлять
В ответ на вопрос в комментариях от @sleepyhead, вот моя настройка iptables nat.
Цепочка PREROUTING (политика ACCEPT 13452 пакетов, 4312К байт)
pkts bytes target prot opt in out source target
Цепочка INPUT (политика ACCEPT 48 пакетов, 12715 байт)
pkts bytes target prot opt in out source target
Цепочка OUTPUT (политика ACCEPT 87 пакетов, 10884 байта)
pkts bytes target prot opt in out source target
Цепочка POSTROUTING (политика ACCEPT 55 пакетов, 8622 байта)
pkts bytes target prot opt in out source target
32 2262 МАСКАРАД все -- * wlp3s0 0.0.0.0/0 0.0.0.0/0
Обновление 2
Возможно ли, что это артефакт того, как я провожу тест? Что вызывает у меня подозрения, так это исходный IP-адрес вывода tcpdump. Может быть, запуск DHCP Discover на интерфейсе, у которого уже есть IP-адрес, дает другой результат, чем если бы его не было? В любом случае, если я смогу переназначить один из моих Raspberry Pis, я запущу этот тест с ним в качестве DHCP-клиента и посмотрю, получу ли я тот же результат, хотя я подозреваю, что получу.
