On 9/20/23 07:10, Genes Lists wrote:
You brought this up in Feb [1] and then as now, I don't understand what actual
problem you're facing. Inbound 'blocked ranges' (SYN packets) should have no
effect. Nothing is 'inbound' to your machines other than replies initiated
from your machine - i.e. ESTABLISHED,RELATED. So if you're not able to get
replies from arch web servers back to your own machines, then likely your
firewall rules are incorrect.
As per the earlier thread, WKD is simply a "web key directory" service - so
all the application is doing is pulling from a web server.
Unless you're blocking outbound packets to such web servers everything should
just work provided you allow arch to reply when you go their web servers.
You should not need any nftables (or legacy iptables) rules provided you allow
client machine to have access to the web servers.
One caveat would be if using nftables instead of iptables. nftables supports 2
kinds of blocks - 'netdev' and 'inet'. 'inet' are the normal blocks. 'netdev'
blocks very early - and any IPs blocked at that level would not allow inbound
or even replies. For anything you want to get replies for you should use
'inet' blocks not netdev. iptables didn't have netdev blocks available last I
used it several years ago.
What problem do you actually have?
Genes,
You helped greatly with your model nftables.conf! Thank you! Things worked
great. I used that to find out how to do the same thing in iptables.
The problem is Archlinux now uses Hetzner as the cloud provider with most
of the Arch IPs falling in the 95.216.xx.xx range. Unfortunately, there is a
lot of miscreants that attempt intrusions from that range so it is dropped in
my iptables setup. I had tried to whitelist (ACCEPT) specific Arch IPs, but
the archlinux-keyring-wkd-sync was illusive to get a stable IP for.
This causes the journal fill with hundreds of thousands of lines of cruft.
It makes 'audit' look like a nice journal user. This is compounded by the
service file including:
Restart=on-failure
RestartSec=5minutes
Your solution of enabling related, established connections worked, but for
those who are not steeped in iptables lore, it wasn't immediately apparent
that provided the solution.
archlinux-keyring-wkd-sync flies under the RADAR on install as a dependent
package whose service file is automatically. Rather than the user having to do
something more to ensure archlinux-keyring-wkd-sync can run, I would propose:
(1) having archlinux-keyring-wkd-sync check connectivity and for a firewall
and add a temporary rule whitelisting the IP it will use so the burden isn't
on the user; or
(2) on connectivity failure, not restart in perpetuity only to fail again,
and again, and again until it can establish a connection successfully.
Surely we can at least break the sync loop and disable restart when a
connectivity failure occurs and not continue to loop over every signature?
It's fine to let is try and run again on schedule a week later and see if the
connectivity has gone away.
I would also propose adding the model ntfables and iptables rules to the
wiki, so anyone else faced with the problem of having
archlinux-keyring-wkd-sync fail filling the logs due to a firewall issue have
that information at their disposal.
This was the circumstance and thoughts I had on the issue so I thought I
would pass them along.
And thank you again Genes for originally having provided me with the solution.
--
David C. Rankin, J.D.,P.E.
