☰

Statische Route über die Nftables-Firewall

tag-icon • tag-icon firewall nat centos8 nftables static-routes
Statische Route über die Nftables-Firewall

Ich habe ein Gateway "X" mit 2 NICs

enp0s3 (192.168.0.100) verbunden mit 192.168.0.0/24 (nehmen wir an, dies ist ein WAN-Netzwerk)

enp0s8 (172.16.0.1) verbunden mit 172.16.0.0/24 (vermutlich ein LAN-Netzwerk)

Ich habe mithilfe von nftables eine NAT-Verbindung erstellt, um Hosts im LAN (172.16.0.0/24) das Surfen im Internet über das Gateway „X“ zu ermöglichen.

/etc/nftables/nftables_firewall

flush ruleset
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state {established, related} accept
    ct state invalid drop
    iifname lo accept
    iifname enp0s8 accept
    ip protocol icmp accept
    reject
  }

  chain forward {
    type filter hook forward priority 0;
    oifname enp0s3 accept
    iifname enp0s3 ct state related, established accept
    iifname enp0s3 drop
  }

  chain output {
    type filter hook output priority 0;
  }

}

/etc/nftables/nftables_nat

flush ruleset
table ip nat {
  chain prerouting {
    type nat hook prerouting priority 0;
  }

  chain postrouting {
    type nat hook postrouting priority 0;
    oifname enp0s3 masquerade
  }
}

Jetzt brauche ich einen Host (192.168.0.101), also einen Laptop aus dem WAN (Netzwerk 192.168.0.0/24), um über das Gateway „X“ auf Hosts im LAN (Netzwerk 172.16.0.0/24) zuzugreifen. Das heißt, ich muss eine statische Route von diesem Host (192.168.0.101) im WAN zum LAN (Netzwerk 172.16.0.0/24) konfigurieren.

Dies ist die statische Route, die ich auf dem Laptop hinzufügen möchte, der sich über seine wlo1-Schnittstelle im Netzwerk 192.168.0.0/24 befindet

ip route add 172.16.0.0/24 via 192.168.0.100 dev wlo1

Die Regeln in der Gateway-Firewall blockieren, dass diese Pakete in das Netzwerk 172.16.0.0/24 gelangen.

Wie lasse ich dies auf meinem Gateway zu?

Ich weiß, dass die Pakete von den Firewall-Regeln verworfen werden, weil

Testen mit

ping 172.16.0.2

von 192.168.0.101 während der Ausführung

tcpdump -lnni any src 192.168.0.101

vom Gateway "X" antwortet

11:41:53.240815 IP 192.168.0.101 > 172.16.0.2: ICMP echo request, id 8, seq 1, length 64
11:41:54.243947 IP 192.168.0.101 > 172.16.0.2: ICMP echo request, id 8, seq 2, length 64
11:41:58.247687 ARP, Request who-has 192.168.0.100 tell 192.168.0.101, length 46

Antwort1

DeinzweiRegelsätze haben einen Fehler:

flush ruleset

Wenn beide nacheinander ausgeführt werden, flush rulesetbleibt davon nur der letzte übrig.

Jedes flush rulesetsollte wie folgt geändert werden:

table inet filter
delete table inet filter

Und:

table ip nat
delete table ip nat

um jedes Mal eine idempotente Tabellendefinition zu erhalten, die weder beim ersten Gebrauch fehlschlägt, sich selbst dupliziert noch dieandereTisch.

Nun zur Frage: Es ist ganz einfach, eine Weiterleitungsregel einzufügen, um dies an der richtigen Stelle zu ermöglichen: vor der Drop-Regel, also entweder:

# nft insert rule inet filter forward index 2 ip saddr 192.168.0.101 ip daddr 172.16.0.0/24 accept

oder aber:

# nft add rule inet filter forward index 1 ip saddr 192.168.0.101 ip daddr 172.16.0.0/24 accept

zu testen,

oder direkt durch Bearbeiten des Regelsatzes an der richtigen Stelle, um ihn beizubehalten:

...
iifname enp0s3 ct state related, established accept
ip saddr 192.168.0.101 ip daddr 172.16.0.0/24 accept
iifname enp0s3 drop
...

Für zusätzliche Sicherheit kann der Regel optional ein iifname enp0s3(=> ) hinzugefügt werden.iifname enp0s3 ip saddr 192.168.0.101 ip daddr 172.16.0.0/24 accept

Der Rückverkehr wird bereits durch die Stateful-Regel ( ... ct state related, established ...) behandelt.

verwandte Informationen