Hi!
Vielen Dank! Deine Config liest sich auf jeden Fall einfacher, als das
was ich fabriziert habe :D
Eine statische v4 hab ich leider nicht, aber so wie ich das verstehe
reicht dann auch ein `ip saddr 192.168.0.0/24 oifname "ppp0" masquerade`?
Ich glaube was mir beim übersetzen meiner firehol config nach nft schwer
fällt ist, dass firehol interfaces und router kennt und ich bei nft nur
chains habe, in denen dann dann diese dinge definiert werden. Im
nftables wiki war als Beispiel doe Konfiguration mit einzelnen chains
pro Interface und dann einer `iifname vmap`.
LG Sebastian
Am 08.01.2025 um 19:56 schrieb [email protected]:
On 2025-01-07 09:54, reox via Debienna wrote:
Ich plane meinen heimischen Router von firehol auf nftables zu ändern.
Hat jemand das hier schon mal gemacht und hat ein paar Tipps?
Insbesondere: Nimmt man heute überhaupt Plain-nftables? Firewalld wird
oft empfohlen (zB auch im Debian Wiki) aber XML-Configs finde ich
nicht schön... (Ja, ich kenne Elektra ;))
Insbesondere was die "router" und IPv4/v6 dual Stack angeht verstehe
ich das Prozerdere bei nftables noch nicht so ganz. Das nftables Wiki
ist auch nicht so hilfreich, da dort meines Erachtens immer wieder
andere Varianten gezeigt werden, die aber irgendwie nirgends erklärt
werden.
Eine dual Stack Konfiguration (idealerweise von A1 mit PPPoE) als
Referenz würde mir vermutlich auch mal helfen!
hi,
ich verwende plain nftables, wo es geht; auf servern, wo libvirt
firewalld nutzt, verwende ich in firewalld nftables als backend und kann
das, was da rauskommt, dank der unabhängigen tables mit rules mit
niedrigerer prio nochmal mit plain nft einschränken (applikationen
können so ein stück weit in der firewall config kooperieren). wichtig zu
verstehen ist am anfang wohl, dass ein drop und reject final sind, aber
ein accept nicht: da werden noch andere tables durchlaufen, soweit
vorhanden.
dual stack kannst du soweit wie möglich mit der address family inet
abdecken (eine table kann nur rules einer family enthalten; für IPv4
nimm ip, für IPv6 ip6), die rules müssen dann ip oder ip6 spezifizieren.
für ipv6 musst du klarerweise neighbor discovery duchlassen, und auch
router advertisements wirst du vermutlich nicht verschmähen.
ich häng mal eine reduzierte und editierte nft config von einem system
mit externem ppp0 und lan-seitigen lan0 interface und fixer public ip
55.55.55.55 an, wo auch dhcp4 und dhcp6 laufen, ssh rein- und
durchgelassen wird, und auch port 80 von einem bestimmten host/netz an
einen anderen lan-seitigen host (192.168.0.2) ge-dnat-ted wird (in einer
eigenen ipv4 table, in der auch der geforwardete outgoing traffic an
public interface ge-snat-ted wird). die zeilen mit nur accept oder drop
sind redundant.
zum testen würde ich eine test-umgebung verwenden ;)
vielleicht noch zur entwirrung: die table und chain names sind beliebig,
wichtig ist, dass in chains mit bestimmten prios an hooks den paketen
auflauern und sie filtern oder modifizieren; das kann in mehreren chains
in verschiedenen tables mit unterschiedlichen prios (-> reihenfolge)
passieren; die basisinfos sind eigentlich ganz gut auf dieser page
zusammengefasst: https://wiki.nftables.org/wiki-nftables/index.php/
Netfilter_hooks ; die bridge und arp layers (blau und rot) kann du
erstmal ignorieren; und welche chain types in welchen address families
an welchen hook operieren können, sagt die farbige tabelle.
lg ibu
_______________________________________________
Debienna mailing list
[email protected]
https://lists.metalab.at/mailman/listinfo/debienna
