У меня есть роутер dd-wrt с двумя интерфейсами Wi-Fi ( ath0, ath1). Я хочу, чтобы все, что включено, ath0не имело никакого доступа к WAN. Только LAN (к устройству и от него).
Как бы это сделать наиболее простым и надежным способом?
До этого я пробовал это с помощью ath1, добавив виртуальную точку доступа, новый мост для точки доступа и некоторые расширенные настройки маршрутизации и брандмауэра. Это было слишком сложно, и я подумал, что будет намного проще просто использовать мой, в любом случае неиспользуемый, ath0(5 ГГц) интерфейс для этой цели.
Я использую OpenVPN в качестве клиента, что немного усложняет ситуацию. При использовании брандмауэра iptables со старым подходом мне всегда приходилось вручную сбрасывать настройки брандмауэра, потому что файл в /etc/ перезаписывает мои правила ( -Iвверху) из-за VPN, разрешая всем доступ WAN, пока он через VPN. Из-за squashFS я не смог найти способ предотвратить это, и всегда вручную перезаписывать его после сохранения настроек/перезагрузки маршрутизатора не очень приятно. Кроме того, я не уверен, не перезапишет ли он его снова позже.
Я также не хочу ath0иметь доступ VPN. Я не могу использовать iptables с исходным IP, потому что он должен быть для всех клиентов на этом SSID/интерфейсе и как только они подключатся, поэтому я не буду знать IP заранее.
Я пытался найти ответ на этот вопрос, но не смог найти ничего, что подошло бы для моего случая, за исключением слишком продвинутого решения с виртуальной точкой доступа/мостом.
решение1
Предположим, что у вас также есть ebtables(или ebtables-nft) в дополнение к iptablesна маршрутизаторе, и что все интерфейсы (W)LAN являются подчиненными мостами по отношению к одному и тому же главному устройству (скажем, с именем bridge0):
ebtables -I INPUT -i ath0 -j mark --set-mark 0xabcd
iptables -I FORWARD -i bridge0 -m mark --mark 0xabcd -j DROP
(Обратите внимание, что значение оценки 0xabcdявляется произвольным.)
Это приводит к тому, что весь трафик, который поступает на маршрутизатор со стороны "LAN", "оставается в пределах" широковещательного домена. Причина в том, что ebtables' INPUTне включает трафик, который идет от подчиненного моста/порта к другому (т. е. пересылка L2). А для того, что нацелено на сам маршрутизатор (что исходит ath0и, следовательно, помечено), мы не хотим, чтобы они пересылались на L3 (т. е. чтобы иметь возможность перейти из "LAN" в "WAN"/VPN/...).
В качестве альтернативы вы можете сделать это, не полагаясь на iptables или маркировку пакетов:
ebtables -I INPUT -i ath0 -d Unicast -p ip ! --ip-dst $ROUTER_LAN_IP -j DROP
Хотя не тестировалось, -d Unicastпредполагается, что DHCP и так работает. Если вам также нужен IPv6 (трафикдля маршрутизатора на L3) для работы вам, вероятно, понадобится/захотится дополнительная цепочка для большего количества исключений (что позволит вам разрешить DHCP также с другим подходом), например:
ebtables -N ATH0
ebtables -A ATH0 -p ip --ip-dst $ROUTER_LAN_IP -j ACCEPT # unicast
ebtables -A ATH0 -p ip --ip-dport 67 -j ACCEPT # broadcast
ebtables -A ATH0 -p ip ... -j ACCEPT
...
ebtables -A ATH0 -p ip6 ... -j ACCEPT
...
ebtables -A ATH0 -j DROP
ebtables -I INPUT -i ath0 -j ATH0
Но, как видите, последний подход гораздо более неуклюж.
P.S. У меня нет никакого опыта работы со всеми WRT и подобными, поэтому я понятия не имею, как сделать правила xtables постоянными в них. (Хотя, если честно, насколько мне известно, это в любом случае специфично для дистрибутива, даже в «типичных» дистрибутивах Linux.)