WireGuard ограничение доступа к некоторым ip-адресам

nftables

/thread

Благодарю. А можно пример настройки?

можно конечно нахимичить напрямую с iptables/nftables, но зачем, если ты не сетевик? Берешь любой фаервол и блочишь.

$ sudo ufw deny in on <interface> to <range>

для ufw например это как-то так делается.

iptables это и есть файрволл

Да, только iptables не нужен когда есть nftables.

https://wiki.nftables.org/wiki-nftables/index.php/Main_Page

Огромное количество примеров самых разных настроек.

ни одной по существу заданного вопроса не нашел

Плохо искал. RTFM.

Где именно?

Что тебе непонятно в аббривеатуре RTFM? Или ты изучаешь как настроить фаервол самостоятельно или платишь деньги и умные люди настраивают за тебя. Третьего не дано.

iptables, nftables и т.д. - это юзерспейсные конфигурялки для фаервола, который сидит в ядре. И в данном конкретном случае нет никаких причин дергать их напрямую.

Иди учи линукс, чудик)) Вместе с пятизвездочным ртфмщиком

Если Вам нечего сказать по существу заданного вопроса, прошу воздержаться от комментариев. Я попросил реальный пример настройки по ограничению доступа к определенным ip-адресам для клиентов VPN.

Я попросил реальный пример настройки по ограничению доступа к определенным ip-адресам для клиентов VPN.

За вас ещё есть не требуете?

брочел, но ведь они правы. Это на изи гуглиться. Либо попердолиться с настройками разрешённых сетей либо повтыкать в фаервол

Я попросил реальный пример настройки по ограничению доступа к определенным ip-адресам для клиентов VPN.

iptables -A FORWARD -s клиент(или подсеть), которым нельзя -d адрес(или подсеть),на который нельзя -j DROP

можно, вероятно, для более точного совпадения добавить интерфейс. можно, вероятно, переписать это на nft

Необходимо клиентам VPN запретить доступ на сервера, которые находятся в диапазоне 10.130.20.2-10.130.20.7. Вопрос: как это сделать?

Почитал обсуждение и понял, что решать надо административно. Издать указ о запрете ходить в тот диапазон, всем довести под роспись

Указ указом, а если в клиентский ноут откуда либо прилетит троян с шифровальщиком на борту (флешка, почта и т.п.), который запечатает сервера, то указ тут не поможет.

А зачем, простите, нужны такие сервера в общей сети с клиентами, к которым клиентам нельзя обращаться? может быть это пахнет XY проблемой, и стоит не клиентов от серверов изолировать, а на серверах политики доступа настраивать? Или кого-то из взрослых позвать, простите, кто сможет вам архитектуру вашей сети грамотно спроектировать.

прошу воздержаться от комментариев

Нет.

И в данном конкретном случае нет никаких причин дергать их напрямую.

Есть.

Сервера должны быть доступны для АРМ непосредственно в локальной сети предприятия (статичных рабочих мест), клиентам VPN, которым нужен удаленный доступ только к своим рабочим ПК, доступ к северу ни к чему…

только к своим рабочим ПК

в таком случае, каждому роадварриору выдается конкретный фиксированный ip, трафик с которого разрешается до конкретного фиксированного ПК, например.

Да и вообще, если

в клиентский ноут откуда либо прилетит троян с шифровальщиком на борту (флешка, почта и т.п.), который запечатает

пользовательский ПК, который, в свою очередь

запечатает

какой-то из серверов - решение «запретить роадварриорам ходить на сервера» не сработает. инфобез - он немножечко сложнее, чем запретить и непущщать. Особенно, если весь инфобез это «поднял непонятный пайвипиен, хз как оно работает, но надо чтоб подругому»

На клиентских ПК входящий доступ только по порту Radmin (4899), остальное закрыто. Учетка радмина, под которой подключаются юзеры, имеет ограниченные права. Засим описываемое Вами действие не требуется, хотя по уму согласен с Вами.

В общем, разобрался с правилами iptables, правда не до конца. Указал следующее:

iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o wg0 -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -d 10.130.20.10/25 -i wg0 -p tcp -j ACCEPT
iptables -A FORWARD -d 10.130.20.6/25 -i wg0 -p tcp -m multiport --dports 53,389 -j ACCEPT
iptables-save >/etc/iptables/rules.v4

Вообще не вариант, тс не может с куда более простой задачей справится, а в вашем варианте без снифера никак.