| 17 Aug 2021 |
 eyJhb | verifiedNetfilter = { text, modules ? [ ] }:
let
file = pkgs.writeText "netfilter" text;
vmTools = pkgs.vmTools.override {
rootModules =
[
"virtio_pci"
"virtio_mmio"
"virtio_blk"
"virtio_balloon"
"virtio_rng"
"ext4"
"unix"
"9p"
"9pnet_virtio"
"crc32c_generic"
] ++ modules;
};
check = vmTools.runInLinuxVM (
pkgs.runCommand "nft-check"
{
buildInputs = [ pkgs.nftables ];
inherit file;
} ''
set -ex
# make sure protocols & services are known
ln -s ${pkgs.iana-etc}/etc/protocol /etc/protocol
ln -s ${pkgs.iana-etc}/etc/services /etc/services
# test the configuration
nft --file $file
set +x
''
);
in
"#checked with ${check}\n" + text;
this beauty
| 16:12:41 |
 andi- | yeah | 16:18:57 |
|  das_j joined the room. | 16:25:23 |
| das_j | oof is this really the only way? :/ | 16:25:57 |
| das_j changed their display name from Janne Heß to das_j. | 16:26:13 |
| andi- | Another reason to use nft: It does support hardware offloading of rules via TC flower | 16:30:24 |
| andi- | and a surprising amount of nics seem to support that at least partially | 16:30:35 |
| andi- | mlx5 and some random mediatek device support flow table offloading | 16:32:14 |
 Linux Hackerman | oh wow | 16:32:21 |
| Linux Hackerman | On the one hand, I love that we have stuff like runInLinuxVM. On the other, I hate that it's necessary for this 😅 | 16:32:51 |
| andi- | I think you can remove the kernel modules part above but then the closure is bigger. IIRC I copied the modules from our VM tests | 16:33:15 |
| andi- | Unfortunately the code looks like it aborts if you request hw offloading instead of falling back to the software implementation | 16:43:42 |
| andi- | so, I kinda want to replace my APU2 with something that has an mlx5 now. | 16:46:48 |
| das_j | Ah can you tell me when you find something good? Because I have an APU2 as well and I would also prefer something with offloading | 16:48:23 |
 nixinator | where can i read about flow offloading? | 16:48:37 |
| nixinator | is this like checksum offloading? | 16:48:55 |
| eyJhb | In reply to @janne.hess:helsinki-systems.de
oof is this really the only way? :/ Hey, at least you can easily test this, instead of a ton of iptables commands in a row or something :p | 16:52:35 |
| eyJhb | Also.... Atomic switching of rules... | 16:52:51 |
| das_j | In reply to @eyjhb:eyjhb.dk
Hey, at least you can easily test this, instead of a ton of iptables commands in a row or something :p But it doesn't really scale for a bunch of cloud nodes that all have their own local firewalls | 16:52:59 |
| eyJhb | Why not? | 16:53:17 |
| das_j | You wouldn't use it for networking.firewall on all devices | 16:53:17 |
| Linux Hackerman | why not? | 16:53:20 |
| das_j | oof | 16:53:23 |
| eyJhb | Bøf | 16:53:27 |
| das_j | Because it spawns a VM for every simple firewall change? That feels kind of wasteful and slow | 16:53:43 |
| das_j | If I want changes on my systems to take ages, I have Ansible right here | 16:54:00 |
| Linux Hackerman | It is a tiny VM though. | 16:54:01 |
 CRTified | In reply to @janne.hess:helsinki-systems.de
Because it spawns a VM for every simple firewall change? That feels kind of wasteful and slow But if there's a way to test something, not testing it seems more wasteful 🤔 | 16:54:08 |
| CRTified | In reply to @janne.hess:helsinki-systems.de
Because it spawns a VM for every simple firewall change? That feels kind of wasteful and slow * But if there's a way to test something beforehand, not testing it seems more wasteful 🤔 | 16:54:14 |
| Linux Hackerman | presumably eyJhb or andi- can say more regarding how quickly that VM runs (I don't use nftables yet), but runInLinuxVM is pretty minimalistic — it spins up the kernel, mounts the store, runs the derivation build script, and shuts down again. I don't think it would take more than 2 or 3 seconds. | 16:56:31 |
