Как остановить трафик на диапазон RC1918 в Ubuntu 20.04?

Question

[Pifagorr]

Суть вопроса в чем, у меня есть vpn сервис(pritunl) на хостере hetzner. Они постоянно присылают мне абузы из-за использования диапазона rc1918. Настроил блокировку трафика через UFW брандмауэр, но это не помогло от слова совсем, абузы также летят как и раньше. В итоге их суппорт теперь рекомендует именно остановить трафик, а не блокировать его. Как мне это сделать, с помощью чего?

Comments

[pfg21]

посмотреть какоето твое ПО генерит трафик с адресами частных сетей :)
настроить ПО так что бы оно не использовало ентих адресов :)
и т.д. каков вопрос - таков ответ.

[Pifagorr]

pfg21, приложение open vpn использует частную сеть 192.168.0.0. То есть получается, что по итогу мне надо искать нового хостера?)) Они пишут, что не против самого vpn, я им все расписывал, что используется на сервере. А по факту значит не судьба с ними сотрудничать, печально.

[Valentin Barbolin]

Скорее всего ты недоконца настроил NAT на hetzner и некоторые пакеты вылетают в сеть не маскированные.
Покажи правила NAT на hetzner
iptables-save

[AlexVWill]

приложение open vpn использует частную сеть 192.168.0.0.

Настрой на использование другой подсети, 10.10.10.0 к примеру.
В server.conf поменяй параметр server на

server 10.10.10.0 255.255.255.0

[Pifagorr]

Valentin Barbolin, # Generated by iptables-save v1.8.4 on Mon May 22 10:55:01 2023
*nat
:PREROUTING ACCEPT [1639079:277138929]
:INPUT ACCEPT [67329:5188358]
:OUTPUT ACCEPT [345:27272]
:POSTROUTING ACCEPT [388:28916]
-A POSTROUTING -s 192.168.220.0/24 -o enp9s0 -m comment --comment pritunl-6464a64bc82bd7b46c9a5bca -j MASQUERADE
-A POSTROUTING -s 192.168.215.0/24 -o enp9s0 -m comment --comment pritunl-6458b11fc82bd7b46cba08c9 -j MASQUERADE
-A POSTROUTING -s 192.168.221.0/24 -o enp9s0 -m comment --comment pritunl-6446d0dcc82bd7b46ccb7724 -j MASQUERADE
-A POSTROUTING -s 192.168.239.0/24 -o enp9s0 -m comment --comment pritunl-64392dc1c82bd7b46c7d01ff -j MASQUERADE
-A POSTROUTING -s 192.168.237.0/24 -o enp9s0 -m comment --comment pritunl-644394fdc82bd7b46cad7d70 -j MASQUERADE
COMMIT
# Completed on Mon May 22 10:55:01 2023
# Generated by iptables-save v1.8.4 on Mon May 22 10:55:01 2023
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [5813:298139]
:OUTPUT ACCEPT [580:92687]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-output - [0:0]
:ufw-logging-allow - [0:0]
:ufw-logging-deny - [0:0]
:ufw-not-local - [0:0]
:ufw-reject-forward - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-skip-to-policy-forward - [0:0]
:ufw-skip-to-policy-input - [0:0]
:ufw-skip-to-policy-output - [0:0]
:ufw-track-forward - [0:0]
:ufw-track-input - [0:0]
:ufw-track-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
:ufw-user-logging-forward - [0:0]
:ufw-user-logging-input - [0:0]
:ufw-user-logging-output - [0:0]
:ufw-user-output - [0:0]
-A INPUT -i tun4 -m comment --comment pritunl-6464a64bc82bd7b46c9a5bca -j ACCEPT
-A INPUT -i tun3 -m comment --comment pritunl-6458b11fc82bd7b46cba08c9 -j ACCEPT
-A INPUT -i tun2 -m comment --comment pritunl-6446d0dcc82bd7b46ccb7724 -j ACCEPT
-A INPUT -i tun0 -m comment --comment pritunl-64392dc1c82bd7b46c7d01ff -j ACCEPT
-A INPUT -i tun1 -m comment --comment pritunl-644394fdc82bd7b46cad7d70 -j ACCEPT
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -o tun4 -m comment --comment pritunl-6464a64bc82bd7b46c9a5bca -j ACCEPT
-A FORWARD -o tun3 -m comment --comment pritunl-6458b11fc82bd7b46cba08c9 -j ACCEPT
-A FORWARD -i tun4 -m comment --comment pritunl-6464a64bc82bd7b46c9a5bca -j ACCEPT
-A FORWARD -i tun3 -m comment --comment pritunl-6458b11fc82bd7b46cba08c9 -j ACCEPT
-A FORWARD -o tun2 -m comment --comment pritunl-6446d0dcc82bd7b46ccb7724 -j ACCEPT
-A FORWARD -o tun0 -m comment --comment pritunl-64392dc1c82bd7b46c7d01ff -j ACCEPT
-A FORWARD -o tun1 -m comment --comment pritunl-644394fdc82bd7b46cad7d70 -j ACCEPT
-A FORWARD -i tun2 -m comment --comment pritunl-6446d0dcc82bd7b46ccb7724 -j ACCEPT
-A FORWARD -i tun0 -m comment --comment pritunl-64392dc1c82bd7b46c7d01ff -j ACCEPT
-A FORWARD -i tun1 -m comment --comment pritunl-644394fdc82bd7b46cad7d70 -j ACCEPT
-A FORWARD -m string --string "info_hash" --algo bm --to 65535 -j DROP
-A FORWARD -m string --string "announce" --algo bm --to 65535 -j DROP
-A FORWARD -m string --string "torrent" --algo bm --to 65535 -j DROP
-A FORWARD -m string --string "announce.php?passkey=" --algo bm --to 65535 -j DROP
-A FORWARD -m string --string ".torrent" --algo bm --to 65535 -j DROP
-A FORWARD -m string --string "peer_id=" --algo bm --to 65535 -j DROP
-A FORWARD -m string --string "BitTorrent protocol" --algo bm --to 65535 -j DROP
-A FORWARD -m string --string "BitTorrent" --algo bm --to 65535 -j DROP
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -o tun4 -m comment --comment pritunl-6464a64bc82bd7b46c9a5bca -j ACCEPT
-A OUTPUT -o tun3 -m comment --comment pritunl-6458b11fc82bd7b46cba08c9 -j ACCEPT
-A OUTPUT -o tun2 -m comment --comment pritunl-6446d0dcc82bd7b46ccb7724 -j ACCEPT
-A OUTPUT -o tun0 -m comment --comment pritunl-64392dc1c82bd7b46c7d01ff -j ACCEPT
-A OUTPUT -o tun1 -m comment --comment pritunl-644394fdc82bd7b46cad7d70 -j ACCEPT
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j ACCEPT
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-input -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-input -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22 -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
-A ufw-user-output -s 10.0.0.0/8 -o eth0 -j DROP
-A ufw-user-output -s 172.16.0.0/12 -o eth0 -j DROP
-A ufw-user-output -s 192.168.0.0/16 -o eth0 -j DROP
COMMIT
# Completed on Mon May 22 10:55:01 2023

[Pifagorr]

AlexVWill, Там дело в том, что конфиг создается на сервере Pritunl с заданными параметрами для подключения. Поэтому тогда он вообще попросту не будет подключаться. Сейчас вижу ребята пишут про nat, попробую с ним еще разобраться.

[Pifagorr]

Valentin Barbolin, Что скажешь?

[Valentin Barbolin]

Pifagorr,

:POSTROUTING ACCEPT [388:28916]
-A POSTROUTING -s 192.168.220.0/24 -o enp9s0 -m comment --comment pritunl-6464a64bc82bd7b46c9a5bca -j MASQUERADE
-A POSTROUTING -s 192.168.215.0/24 -o enp9s0 -m comment --comment pritunl-6458b11fc82bd7b46cba08c9 -j MASQUERADE
-A POSTROUTING -s 192.168.221.0/24 -o enp9s0 -m comment --comment pritunl-6446d0dcc82bd7b46ccb7724 -j MASQUERADE
-A POSTROUTING -s 192.168.239.0/24 -o enp9s0 -m comment --comment pritunl-64392dc1c82bd7b46c7d01ff -j MASQUERADE
-A POSTROUTING -s 192.168.237.0/24 -o enp9s0 -m comment --comment pritunl-644394fdc82bd7b46cad7d70 -j MASQUERADE
COMMIT

Где маскарад для этих сетей?

приложение open vpn использует частную сеть 192.168.0.0.

[Pifagorr]

Valentin Barbolin, Добавил новые настройки:
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/8 -j MASQUERADE
-A POSTROUTING -s 172.16.0.0/12 -j MASQUERADE

Как думаешь, достаточно будет? Или лучше на всякий случай еще дропнуть исходящий трафик с eth0 для того же диапазона RC1918?

[Valentin Barbolin]

Pifagorr,

-A POSTROUTING -o eth0 -j MASQUERADE

Вот это перекрывает все правила. Только судя по iptables-save интерфейс у тебя enp9s0, а ты указал eth0.

[Pifagorr]

Valentin Barbolin, Ломаю голову как правильно прописать тогда ее для iptables )) Я не особо сильно шарю в убунте.

sudo iptables -A OUTPUT -d 192.168.0.0/16 -j DROP # - вот где тут правильно вписать eth0 ?

[Valentin Barbolin]

Pifagorr, У тебя ведь ufw стоит. Проверь имя интерфейса (ip ad)

ufw deny out on eth0 to 192.168.0.0/16

sudo iptables -A OUTPUT -d 192.168.0.0/16 -j DROP # - вот где тут правильно вписать eth0 ?

Чисто технически вот так
sudo iptables -A OUTPUT -o eth0 -d 192.168.0.0/16 -j DROP

[Pifagorr]

Valentin Barbolin, "Вот это перекрывает все правила. " - тоесть если это правило стоит, то остальные не обязательно прописывать было? Или лучше удалить его и оставить эти
-A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/8 -j MASQUERADE
-A POSTROUTING -s 172.16.0.0/12 -j MASQUERADE

"Только судя по iptables-save интерфейс у тебя enp9s0, а ты указал eth0." - ваа, здорово. И что тогда удалить и переписать для enp9s0?

[Valentin Barbolin]

Pifagorr,

И что тогда удалить и переписать для enp9s0?

Для начала точно определить какое имя у интерфейса (ip ad).

[Valentin Barbolin]

Pifagorr, Тогда достаточно одного правила
sudo iptables -t nat -I POSTROUTING -o enp9s0 -j MASQUERADE

[Pifagorr]

Valentin Barbolin, 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp9s0: mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether a8:a1:59:94:1a:c0 brd ff:ff:ff:ff:ff:ff
inet scope global enp9s0
valid_lft forever preferred_lft forever
inet6 scope global
valid_lft forever preferred_lft forever
inet6
scope link
valid_lft forever preferred_lft forever

enp9s0 видимо все таки он. теперь стыдно становится.

[Pifagorr]

Valentin Barbolin, Огромное спасибо! Буду пробовать, проверять. Надеюсь больше абузов не увижу от хостера. Напиши хоть номер свой, скину тебе донат небольшой за помощь. Спасибо что есть такие неравнодушные люди как ты, которые подсказывают таким нубаям как я :))

[Pifagorr]

Valentin Barbolin, и последний вопрос думаю. Важно ли удалить остальные правила или т.к. это правило в начале списка, оно автоматически перебьет остальные? Нужно ли отключить ufw(не будет ли конфликта с iptables) или можно его оставить?

[AUser0]

Valentin Barbolin, Pifagorr, кажется маскарадинг не поможет, приватные пакеты прекрасно дойдут до второго конца туннеля, просто замаскараденные приватным IP самого сервера. А нужно блокировать эти пакеты, в корне. Только непонятно, а для чего вообще подняли этот туннель, и почему в него попадают пакеты, для этого не предназначенные?

Answer 1

[Drno]

А при чем тут хостер, если ты виноват?))

С помощью iptables дропни все исходящие с eth0 (или какой там у тебя интерфейс) на приватные адреса

У кого то из твоих впнщиков сидит вирусня/сканер/етс

Comments

[Pifagorr]

-A ufw-user-output -s 10.0.0.0/8 -o eth0 -j DROP
-A ufw-user-output -s 172.16.0.0/12 -o eth0 -j DROP
-A ufw-user-output -s 192.168.0.0/16 -o eth0 -j DROP

Я настраивал с ufw, не помогло.

[AUser0]

Pifagorr, блокировать приватные подсети на физическом (!) интерфейсе, когда они (видимо) пролазят в виртуальный интерфейс VPN-а?! Серьёзно?

[Drno]

AUser0, какая разница где они пролазят. Хетзнер не устраивает то, что они лезут по их сети, запросы с этого сервера. Так что их как раз и нужно блокировать на физ интерфейсе. внутри хоста \ впн сети - пусть че угодно делают, какая разница то.

[Drno]

Pifagorr, я не пользуюсь ufw, так что не могу тут ничего сказать. ради теста попробуй сконвертировать правила в Iptables. ну я бы так делал

[Pifagorr]

Drno, Сейчас попробую да, заодно и nat маскарад настрою как советовали выше.

[Pifagorr]

Drno, Скорее всего кто-то из пользователей с вирусняком/сканером, тут ты прав.

[AUser0]

Drno, стоп-стоп-стоп. В чём смысл VPN? В том, что обычный TCP-пакет (с RFC1918) упаковывается внутрь другого TCP-пакета, который и доставляется на вторую сторону VPN-канала, по физической линии. Так какой же RFC1918 вы рассчитываете увидеть именно на физическом интерфейсе?

[Pifagorr]

AUser0, Бро, я тебе больше скажу, ничего не выдумываю, говорю только то, что советовали сами хетцнеры. Они так и написали, что нужно блокнуть исходящий на eth0 диапазон рфц1918.

[Pifagorr]

Я на всякий случай настроил маскарад и дроп на enp9s0(оказалось именно этот интерфейс).

[Pifagorr]

AUser0, Что ты считаешь можно сделать по другому?

[Drno]

Pifagorr, ну так надо ж было посмотреть имя интерфейса)))

[Pifagorr]

Drno, я ж пока только детеныш айтишника)))

[Drno]

AUser0, юзер VPN подключился к серверу. далее все его пакеты пошли через VPN (если мы говорим про то, что он стал основным шлюзом), значит и какая то вирусня \ сканер запросто внутрь этого VPN погонит трафик.
Т.к. мы этот траффик NATим - он в итоге "выйдет" из физического интерфейса сервера... но уже с IP самого сервака...

[AUser0]

Drno, и как смена IP помешает вредоносности трафика? Он ведь продолжит литься в прежнем объёме...

[AUser0]

Pifagorr, нужно блокировать не на eth0 (не удивляет, что Хетцнеры сказали именно eth0?), и не на enp9s0, а на виртуальном интерфейсе VPN-канала.

[Drno]

AUser0, он не продолжит литься, если фаерволом просто запретить обращение на эти подсети

[AUser0]

Drno, поэтому его надо именно маскарадить, что бы потом блокировать?

[Pifagorr]

AUser0, хорошо, что ты предлагаешь еще сделать? Каким образом я могу заблочить этот трафик на виртуальном интерфейсе vpn канала? Мониторю пока ситуацию, если придет еще один абуз, то есно нужно что-то другое предпринимать.

[AUser0]

Pifagorr, а чего тут мониторить абузы? Идеш на хетцнеровский сервер, запускаешь tcpdump -nni any net 10.0.0.0/8, и любуешься на трафик, который нужно блокировать. Вместо 10.0.0.0/8 подставь IP-диапазон домашней сети.

[AUser0]

Pifagorr, а блокировать простым -A OUTPUT -o tun0 -s 10.0.0.0/8 -j REJECT, разумеется в начале списка OUTPUT правил, заменив туннель и подсетку на свои.

Только встаёт вопрос - а для чего вообще нужен туннель?

[Pifagorr]

AUser0, чисто инстаграмчик людям смотреть, канва, и все прочее блоченное. Вопрос еще в другом, если я заблочу туннель, не встанет ли vpn сам? Просто тогда смысл от него будет какой.

[AUser0]

Pifagorr, воооот, и это - правильный вопрос! Так и трафик самого сервера тоже заблочится. Разматываем ситауцию дальше. А почему трафик из локальной сети вдруг пошёл этим неожиданным путём? Наверное потому, что скрипты VPN-канала поменяли default route на себя, и весь трафик, направленный не в локальную сеть, вполне ожидаемо попёр в VPN-канал.

Поэтому: вывод ip route - в студию! А я пошёл уже спать.

[Pifagorr]

AUser0, default via dev enp9s0 proto static onlink
192.168.215.0/24 dev tun3 proto kernel scope link src 192.168.215.1
192.168.220.0/24 dev tun4 proto kernel scope link src 192.168.220.1
192.168.221.0/24 dev tun2 proto kernel scope link src 192.168.221.1
192.168.237.0/24 dev tun1 proto kernel scope link src 192.168.237.1
192.168.239.0/24 dev tun0 proto kernel scope link src 192.168.239.1

[Pifagorr]

AUser0, Маскарад реально не помог, как и дроп enp9s0. Только что пришел новый абуз. Причем ругается именно на протокол TCP(у меня в основном сервера на udp). Что еще подметил, абуз приходит уже каждый день примерно в одинаковое время. Тоесть какой-то нехороший юзер на андроиде(скорее всего), заходит каждый вечер после работки и сам не знает, что у него вирусняк или троян. Ну или хитровыдолбанный хакер мамкин в сети завелся. Еще один вариант - я неверно сохранил настройки(хотя проверял, вроде все прописаны в iptables-save).

[Drno]

Pifagorr, покажи правило iptables. Которое ты прописывал

[Pifagorr]

Drno, # Generated by iptables-save v1.8.4 on Tue May 23 07:30:48 2023
*filter
:INPUT ACCEPT [266388164:119271472335]
:FORWARD ACCEPT [10406:498578]
:OUTPUT ACCEPT [598949973:756377539906]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-output - [0:0]
:ufw-reject-forward - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-track-forward - [0:0]
:ufw-track-input - [0:0]
:ufw-track-output - [0:0]
-A INPUT -i tun4 -m comment --comment pritunl-6464a64bc82bd7b46c9a5bca -j ACCEPT
-A INPUT -i tun3 -m comment --comment pritunl-6458b11fc82bd7b46cba08c9 -j ACCEPT
-A INPUT -i tun0 -m comment --comment pritunl-64392dc1c82bd7b46c7d01ff -j ACCEPT
-A INPUT -i tun2 -m comment --comment pritunl-6446d0dcc82bd7b46ccb7724 -j ACCEPT
-A INPUT -i tun1 -m comment --comment pritunl-644394fdc82bd7b46cad7d70 -j ACCEPT
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -o tun4 -m comment --comment pritunl-6464a64bc82bd7b46c9a5bca -j ACCEPT
-A FORWARD -o tun3 -m comment --comment pritunl-6458b11fc82bd7b46cba08c9 -j ACCEPT
-A FORWARD -i tun4 -m comment --comment pritunl-6464a64bc82bd7b46c9a5bca -j ACCEPT
-A FORWARD -i tun3 -m comment --comment pritunl-6458b11fc82bd7b46cba08c9 -j ACCEPT
-A FORWARD -o tun0 -m comment --comment pritunl-64392dc1c82bd7b46c7d01ff -j ACCEPT
-A FORWARD -o tun2 -m comment --comment pritunl-6446d0dcc82bd7b46ccb7724 -j ACCEPT
-A FORWARD -o tun1 -m comment --comment pritunl-644394fdc82bd7b46cad7d70 -j ACCEPT
-A FORWARD -i tun0 -m comment --comment pritunl-64392dc1c82bd7b46c7d01ff -j ACCEPT
-A FORWARD -i tun2 -m comment --comment pritunl-6446d0dcc82bd7b46ccb7724 -j ACCEPT
-A FORWARD -i tun1 -m comment --comment pritunl-644394fdc82bd7b46cad7d70 -j ACCEPT
-A FORWARD -m string --string "info_hash" --algo bm --to 65535 -j DROP
-A FORWARD -m string --string "announce" --algo bm --to 65535 -j DROP
-A FORWARD -m string --string "torrent" --algo bm --to 65535 -j DROP
-A FORWARD -m string --string "announce.php?passkey=" --algo bm --to 65535 -j DROP
-A FORWARD -m string --string ".torrent" --algo bm --to 65535 -j DROP
-A FORWARD -m string --string "peer_id=" --algo bm --to 65535 -j DROP
-A FORWARD -m string --string "BitTorrent protocol" --algo bm --to 65535 -j DROP
-A FORWARD -m string --string "BitTorrent" --algo bm --to 65535 -j DROP
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -o tun4 -m comment --comment pritunl-6464a64bc82bd7b46c9a5bca -j ACCEPT
-A OUTPUT -o tun3 -m comment --comment pritunl-6458b11fc82bd7b46cba08c9 -j ACCEPT
-A OUTPUT -o tun0 -m comment --comment pritunl-64392dc1c82bd7b46c7d01ff -j ACCEPT
-A OUTPUT -o tun2 -m comment --comment pritunl-6446d0dcc82bd7b46ccb7724 -j ACCEPT
-A OUTPUT -o tun1 -m comment --comment pritunl-644394fdc82bd7b46cad7d70 -j ACCEPT
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A OUTPUT -d 192.168.0.0/16 -o enp9s0 -j DROP
-A OUTPUT -d 10.0.0.0/8 -o enp9s0 -j DROP
-A OUTPUT -d 172.16.0.0/12 -o enp9s0 -j DROP
COMMIT
# Completed on Tue May 23 07:30:48 2023
# Generated by iptables-save v1.8.4 on Tue May 23 07:30:48 2023
*nat
:PREROUTING ACCEPT [2123357:363656760]
:INPUT ACCEPT [206149:13185504]
:OUTPUT ACCEPT [1489:93628]
:POSTROUTING ACCEPT [1324:80322]
-A POSTROUTING -s 192.168.220.0/24 -o enp9s0 -m comment --comment pritunl-6464a64bc82bd7b46c9a5bca -j MASQUERADE
-A POSTROUTING -s 192.168.215.0/24 -o enp9s0 -m comment --comment pritunl-6458b11fc82bd7b46cba08c9 -j MASQUERADE
-A POSTROUTING -s 192.168.239.0/24 -o enp9s0 -m comment --comment pritunl-64392dc1c82bd7b46c7d01ff -j MASQUERADE
-A POSTROUTING -s 192.168.221.0/24 -o enp9s0 -m comment --comment pritunl-6446d0dcc82bd7b46ccb7724 -j MASQUERADE
-A POSTROUTING -s 192.168.237.0/24 -o enp9s0 -m comment --comment pritunl-644394fdc82bd7b46cad7d70 -j MASQUERADE
-A POSTROUTING -o enp9s0 -j MASQUERADE
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/8 -j MASQUERADE
-A POSTROUTING -s 172.16.0.0/12 -j MASQUERADE
COMMIT

[Pifagorr]

Тут действительно видно, что pritunl прописал еще и свои правила, потому что я их не делал изначально. Либо реально нужно менять маршрутизацию, либо проверять правила(удалять и заново составлять). Поэтому послушаю, что скажут умные люди нубаю.

[Pifagorr]

Это был выделенный сервер у хетцнеров.

А вот для сравнения облачный сервер, с ним проблем никаких не возникает. Видимо они сами изначально там все настраивают.

ip ad

1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 96:00:02:35:a2:c8 brd ff:ff:ff:ff:ff:ff
inet 37.27.7./32 scope global dynamic eth0
valid_lft 75319sec preferred_lft 75319sec
inet6 2a01:4f9:c012:c3ec::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::9400:2ff:fe35:a/64 scope link
valid_lft forever preferred_lft forever
3: tun0: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
link/none
inet 192.168.230.1/24 brd 192.168.230.255 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::d39f:e43f:4b69:a/64 scope link stable-privacy
valid_lft forever preferred_lft forever

ip route
default via 172.31.1.1 dev eth0 proto dhcp src 37.27. metric 100
172.31.1.1 dev eth0 proto dhcp scope link src 37.27. metric 100
192.168.230.0/24 dev tun0 proto kernel scope link src 192.168.230.1

iptables-save
# Generated by iptables-save v1.8.4 on Tue May 23 05:41:45 2023
*nat
:PREROUTING ACCEPT [164784:23515450]
:INPUT ACCEPT [40300:2098942]
:OUTPUT ACCEPT [230:18128]
:POSTROUTING ACCEPT [230:18128]
-A POSTROUTING -s 192.168.230.0/24 -o eth0 -m comment --comment pritunl-646a3398d240e3dad864ed0f -j MASQUERADE
COMMIT
# Completed on Tue May 23 05:41:45 2023
# Generated by iptables-save v1.8.4 on Tue May 23 05:41:45 2023
*filter
:INPUT ACCEPT [14859307:4517652910]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [38964481:45543523395]
-A INPUT -i tun0 -m comment --comment pritunl-646a3398d240e3dad864ed0f -j ACCEPT
-A FORWARD -o tun0 -m comment --comment pritunl-646a3398d240e3dad864ed0f -j ACCEPT
-A FORWARD -i tun0 -m comment --comment pritunl-646a3398d240e3dad864ed0f -j ACCEPT
-A OUTPUT -o tun0 -m comment --comment pritunl-646a3398d240e3dad864ed0f -j ACCEPT
COMMIT

[Pifagorr]

AUser0, Кстати, на самом интерфейсе Pritunl есть тоже возможность добавить route. Скрин приложу. Стоит изначально по умолчанию 0.0.0.0/0. Пробовал удалять ради интереса, при подключенном впн тогда спидтест показывает местную сеть провайдера)) Есно заблокированные ресурсы сразу не работают, остальные сайты да.

Answer 2

[ValdikSS]

Без дампа захвата трафика и анализа ситуации могу только ткнуть пальцем в небо и предположить, полагая, что у вас корректно настроен NAT (MASQUERADE) из VPN-интерфейса на физический интерфейс, что от VPN-клиентов уходит трафик без подмены адреса (без NAT'а), если TCP-сессия уже была установлена с каким-либо хостом в момент соединения с VPN.

В этом случае, при типичной настройке iptables, правило MASQUERADE не будет выполняться (так как у пакетов состояние conntrack INVALID, а не NEW/ESTABLISHED), и пакеты будут маршрутизироваться без замены исходного адреса.

Решение:

iptables -I FORWARD -m conntrack --ctstate INVALID -j DROP

Аналогичная ситуация может происходить, если кто-то из клиентов генерирует пакеты TCP на низком уровне, без установки TCP-сессии. Например, единичный SYN/ACK-пакет, не принадлежащий какой-либо TCP-сессии, отправленный через VPN, не попадёт под действие NAT MASQUERADE-правила.

Comments

[Pifagorr]

Огромное спасибо! Настроил правило. А маскарад верно настроен да.

Answer 3

[Zerg89]

Прячте трафик за натом тогда весь трафик будет уходить с вашим белым ip

Comments

[Pifagorr]

Спасибо, вот как раз ломаю голову, как все правильно настроить с натом.

Answer 4

[Pifagorr]

Всех благодарю за помощь и предложенные решения проблемы! Помогло в итоге решение ValdikSS sudo iptables -I FORWARD -m conntrack --ctstate INVALID -j DROP
и Drno sudo iptables -A OUTPUT -o enp9s0(тут ваш интерфейс) -d 172.16.0.0/12(тут ваша виртуальная сеть vpn) -j DROP
Надеюсь что вопрос реально исчерпан и хетцнеры отстанут от меня наконец-то.

П.С. Чтобы увидеть сетевой интерфейс, используйте команду ip ad, а чтобы увидеть какие виртуальные сети использует ваш vpn - ip route. Возможно кому-то пригодится, чтобы не рыть всю переписку.

Comments

[Drno]

интерфейсы - ip a )

[Pifagorr]

Drno, d )))