On 2023-09-21 09:52 AM, David C. Rankin wrote:
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.
I still don't understand your issue.
If you're actively blocking outbound to Hetzner ranges then that is a
YOU problem.
Forgive my bluntness, but I think you have a fundamental
misunderstanding of how a firewall works.
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:
Again, this is because of what you seem to be doing and blocking
outbound traffic because you think the other baddies on Hetzner ranges
can get in if you don't blanket block all the IPs.
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.
"Steeped in iptables lore" is a bit of a stretch, the Arch wiki covers
the simplest iptables setup that is elegant and effective. If you're
locking down all traffic and only allowing certain outbound things then,
again, it's a you thing to deal with.
https://wiki.archlinux.org/title/Simple_stateful_firewall
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.
You propose all of this to workaround something you're actively doing /
blocking.
Please don't do any of this Arch, it'd be creating a mess for the rest
of us who adhere to sane defaults.
--
Simon Perry (aka Pezz)
