Hi,
Exploring possibilities for further improvement of the firewall rules,
I ran this test:
# cat test.nft
#!/usr/sbin/nft -f
flush ruleset
table ip t {
chain dnat-dns {
ip daddr 10.139.1.1 udp dport 53 dnat to 10.139.1.1
ip daddr 10.139.1.1 tcp dport 53 dnat to 10.139.1.1
ip daddr 10.139.1.2 udp dport 53 dnat to 10.139.1.2
ip daddr 10.139.1.2 tcp dport 53 dnat to 10.139.1.2
}
chain B {
ip daddr 10.139.1.1 meta l4proto { tcp, udp } th dport 53 dnat
to 10.139.1.1
ip daddr 10.139.1.2 meta l4proto { tcp, udp } th dport 53 dnat
to 10.139.1.2
}
chain C {
dnat to ip daddr . meta l4proto . th dport map {
10.139.1.1 . tcp . 53 : 10.139.1.1,
10.139.1.1 . udp . 53 : 10.139.1.1,
10.139.1.2 . tcp . 53 : 10.139.1.2,
10.139.1.2 . udp . 53 : 10.139.1.2
}
}
}
Looking at the output of 'nft --debug=netlink -f test.nft', it seems
the most optimal version is chain C.
IIUC, chain ip dnat-dns is created by /usr/lib/qubes/qubes-setup-dnat-to-ns.
Unfortunately, my Python skills are extremely limited, so my attempt:
# diff qubes-setup-dnat-to-ns qubes-setup-dnat-to-ns_ORIG
100d99
< 'dnat to ip daddr . meta l4proto . th dport map {',
105,106c104,105
< f"{vm_nameserver} . tcp . 53 : {dns_}",
< f"{vm_nameserver} . udp . 53 : {dns_}",
---
> f"ip daddr {vm_nameserver} udp dport 53 dnat to {dns_}",
> f"ip daddr {vm_nameserver} tcp dport 53 dnat to {dns_}",
108c107
< res += ["}\n}\n}\n"]
---
> res += ["}\n}\n"]
results only in dnat-dns chain not being created at all (and I can't figure
why).
Would anyone be willing to [explain how to] optimize that chain?
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/20240613192637.2bea0675%40localhost.
