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)