UFW-Regeln mit NAT/Masquerading

UFW-Regeln mit NAT/Masquerading

Ich versuche, Ubuntu als eine Art Router zu verwenden, indem ich die Verbindungen eines Computers in meinem privaten Netzwerk mit dem Internet einschränke.

Die Ubuntu-Box hat zwei Netzwerkkarten, eine ist mit dem Internet verbunden (enp0s3), eine ist mit diesem einzelnen privaten PC verbunden (enp0s8).

Zunächst wollte ich sehen, ob ich DNS einfach von der privaten Box über Ubuntu zulassen kann. Ich bin ein paar Anweisungen gefolgt, um einige „Route Allow“-Regeln hinzuzufügen. Das Ergebnis ist:

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 ist mein privater PC. Mit Wireshark kann ich sehen, dass DNS-Anfragen sowohl an enp0s3 als auch an enp0s8 gestellt werden, aber die an enp0s3 erhalten keine Antwort.

Nachdem ich noch ein bisschen mehr gelesen hatte, stellte ich fest, dass ich NAT und Masquerading einrichten musste, also fügte ich Folgendes in rules.before ein:

# 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

Das hat funktioniert – aber zu gut. Jetzt wird der gesamte Datenverkehr raus- und wieder zurückgeleitet, die standardmäßige Ablehnung ausgehender Verbindungen und die anderen UFW-Regeln scheinen alle umgangen zu sein.

Meine Frage ist also einfach: Ich möchte, dass der private PC über Ubuntu eine Verbindung wie das bereitgestellte NAT herstellt, aber mit den ausgehenden Einschränkungen, die ich ursprünglich mit den UFW-Befehlszeilen konfiguriert zu haben glaubte. Gibt es eine Möglichkeit, die UFW-Regeln irgendwie anzuwenden, nachdem das NAT seine Arbeit erledigt hat?

Ich bin dir dankbar.

Hier ist die vollständige Datei before.rules. Meine einzige Änderung betraf die NAT-Tabellenregeln:

#
# 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

Antwort1

Es scheint, dass Routing-/Weiterleitungsregelnvöllig getrenntzu normalen Firewall-Regeln. Ich habe das NAT-Zeug nach after.rules verschoben und die Standardregel für „gerouteten“ Verkehr auf „denk“ geändert. Es scheint, dass POSTROUTING auftrittnachdie Standard-Ablehnungsregel wird angewendet - wenn also etwas durch die Standardregel abgelehnt wird, wird es nicht per NAT weitergeleitet. Es ist natürlich möglich, Benutzerregeln hinzuzufügen (von der Art „ufw route allow ...“) und diese können Verkehr zulassen, bevor die Standard-Ablehnungsregel angewendet wird, und dieser wird dann wie erwartet weitergeleitet.

verwandte Informationen