☰

Правила UFW с NAT/маскарадингом

tag-icon • tag-icon ufw routing
Правила UFW с NAT/маскарадингом

Я пытаюсь использовать Ubuntu в качестве своего рода маршрутизатора, ограничивая компьютер в моей частной сети тем, к чему он может подключиться через Интернет.

В Ubuntu Box имеется две сетевые карты, одна из которых подключена к Интернету (enp0s3), а другая — к этому частному ПК (enp0s8).

Для начала я хотел посмотреть, смогу ли я просто разрешить DNS из частного ящика через Ubuntu. Я следовал некоторым инструкциям, чтобы добавить некоторые правила «route allow», например, вот что получилось:

ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), deny (outgoing), allow (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
8.8.8.8 on enp0s3          ALLOW FWD   Anywhere on enp0s8        
8.8.4.4 on enp0s3          ALLOW FWD   Anywhere on enp0s8        
10.0.1.5 on enp0s8         ALLOW FWD   Anywhere on enp0s3

10.0.1.5 — мой личный ПК. Используя Wireshark, я вижу, что DNS-запросы делаются как на enp0s3, так и на enp0s8, но на запросы на enp0s3 ответа нет.

Итак, почитав еще немного, я обнаружил, что мне нужно настроить NAT и маскировку, поэтому я добавил следующее в rules.before:

# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Forward traffic through eth0 - Change to match you out-interface
-A POSTROUTING -s 10.0.1.0/24 -o enp0s3 -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't
# be processed
COMMIT

Это сработало, но слишком хорошо. Теперь весь трафик выходит и возвращается на мой личный ПК, запрет исходящих по умолчанию и другие правила UFW, похоже, обходятся.

Итак, мой вопрос прост - я хочу, чтобы частный ПК получил подключение через Ubuntu, как это предусмотрено NAT, но с исходящими ограничениями, которые я изначально настроил с помощью командных строк ufw. Есть ли способ заставить правила UFW как-то применяться после того, как NAT сделает свое дело?

ТИА.

Вот полный файл before.rules. Единственное, что я изменил, это правила таблицы NAT:

#
# rules.before
#
# Rules that should be run before the ufw command line added rules. Custom
# rules should be added to one of these chains:
#   ufw-before-input
#   ufw-before-output
#   ufw-before-forward
#

# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Forward traffic through eth0 - Change to match you out-interface
-A POSTROUTING -s 10.0.1.0/24 -o enp0s3 -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't
# be processed
COMMIT


# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines


# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT

# quickly process packets for which we already have a connection
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# drop INVALID packets (logs these in loglevel medium and higher)
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP

# ok icmp codes for INPUT
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT

# ok icmp code for FORWARD
-A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT

# allow dhcp client to work
-A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT

#
# ufw-not-local
#
-A ufw-before-input -j ufw-not-local

# if LOCAL, RETURN
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN

# if MULTICAST, RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN

# if BROADCAST, RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN

# all other non-local packets are dropped
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP

# allow MULTICAST mDNS for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT

# allow MULTICAST UPnP for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

решение1

Кажется, что правила маршрутизации/пересылкиполностью отдельныйна обычные правила брандмауэра. Я переместил NAT-вещи в after.rules и изменил правило по умолчанию для "маршрутизированного" трафика на "запретить". Похоже, что происходит POSTROUTINGпослеприменяется правило запрета по умолчанию - поэтому если что-то запрещено правилом по умолчанию, оно не будет маршрутизировано nat. Конечно, можно добавить пользовательские правила (типа "ufw route allow ..."), и они могут разрешить трафик до применения правила запрета по умолчанию, и тогда он будет маршрутизирован, как и ожидалось.

Связанный контент