Table des matières
2026/03/21 Neutriton : nftables
Météo
Moment informel durant lequel on exprime en peu de mots comment on se sent et si on a une attente forte pour la réunion.
Ce n'est pas un moment de discussion mais d'expression individuelle et ce n'est pas obligatoire 
Attente(s) forte(s)
Si l'une ou l'autre personne exprime une attente forte, merci de vous en occuper en priorité ou de la noter dans le hub ou dans un point approprié.
FIN: 14h
Flowtables et nftables
C'est quoi ?
Dans Nftables, nous allons parler de flowtables.
https://wiki.nftables.org/wiki-nftables/index.php/Flowtables
Flowtables s'applique autant à Neutrinet que sur les Mikrotik. Partout où il y a du Nftables.
On est au niveau du kernel. C'est là que se prenent plein de décisions.
Le qdisc c'est l'endroit où on va réordonner les paquets en fonction des règles de qualité de service (qos). Dans le cas de Neutrinet, on utilise cake (rien à voir avec le dessert) que ce soit sur Mikrotik ou les VM edges pour prioritiser les paquets VOIP, ICMP, etc. C'est un protocole qui permet de réduire la latence dans les applications.
Netfilter est dans le kernel et permet de gérer le firewall.
Le point commun entre nftables et iptables : tous les deux parlent à netfilter comment il doit se comporter pour les paquets réseaux. Certaines règles iptables sont convertible nftables et vice versa (et réciproquement). On parle le même langage d'un point de vue technique.
On arrive ensuite au prerouting (NAT), puis routing, puis forward (NAT again), et postrouting (à nouveau NAT). En gros, quand on rajoute des règles firewall pour le routing, postrouting, ça se met dans cette table-là.
On est ensuite au point 10, où il y a à nouveau du qdisc car on peut appliquer des règles de priorité en sortie.
Telle est la dure vie d'un paquet réseau dans le kernel. Il traverse plein de couches.
À partir du point 1 ou 2, on a ce qu'on appelle des connection tracking, des conntrack.
Ce qu'il y a ci-dessous est un exemple de ce qui sort de la VM Verixi :
- snippet.bash
root@edge-verixi-01:~# conntrack -L icmpv6 58 26 src=2a05:d01c:68f:ef02:767e:bf7a:fb92:df39 dst=2a00:1528:3201:5::22 type=128 code=0 id=11 src=2a00:1528:3201:5::22 dst=2a05:d01c:68f:ef02:767e:bf7a:fb92:df39 type=129 code=0 id=11 mark=0 use=1 icmpv6 58 22 src=2406:da1e:4b7:e601:2a92:4b57:ffa6:d0 dst=2a00:1528:3201:5::22 type=128 code=0 id=5 src=2a00:1528:3201:5::22 dst=2406:da1e:4b7:e601:2a92:4b57:ffa6:d0 type=129 code=0 id=5 mark=0 use=1 icmpv6 58 22 src=2a05:d018:bb5:3300:9bd:bf1:3b4b:a67 dst=2a00:1528:3201:5::22 type=128 code=0 id=5 src=2a00:1528:3201:5::22 dst=2a05:d018:bb5:3300:9bd:bf1:3b4b:a67 type=129 code=0 id=5 mark=0 use=1 icmpv6 58 22 src=2a05:d016:268:8b02:88fa:8046:98fd:7db4 dst=2a00:1528:3201:5::22 type=128 code=0 id=6 src=2a00:1528:3201:5::22 dst=2a05:d016:268:8b02:88fa:8046:98fd:7db4 type=129 code=0 id=6 mark=0 use=1 ... dst=2a00:1528:3201:5::22 type=128 code=0 id=5 src=2a00:1528:3201:5::22 dst=2a05:d011:d07:5800:9e8d:993:ff98:b712 type=129 code=0 id=5 mark=0 use=1 conntrack v1.4.7 (conntrack-tools): 55 flow entries have been shown.
On voit du charabia de réseau, l'important c'est de voir qu'à ce stade on a l'information de la source et de la destination, le port source et destination également, la taille des paquets, le protocole, etc.
Flowtable s'applique quand un paquet a déjà subit une prise de déciion (prérouting, routing, postrouting.). La décision est conservée et va être appliquée aux autres parquets (source, destination, etc.). En gros, le paquet et cela garde en mémoire ce qui a été calculé, ce qui évite de calculer à chaque fois. Par défaut, ce n'est pas dans Debian, parce qu'il peut pas le deviner comme ça. On doit dire dans nftables : tu vois ces paquets, ben ils peuvent utiliser flowtable pour aller plus vite (parce que nous on sait que c'est ok de faire ça sur ce type de paquets).
Configuration
Comment on configure tout ça ? Il suffit de faire la commande : tharyrok config nftables
Presque…
table inet my_table {
flowtable f {
hook ingress priority filter
devices = { bond0.10, bond0.20, bond0.30, bond0.40, ppp0 }
}
chain my_input {
type filter hook input priority filter; policy drop;
iif "lo" accept comment "Accept any localhost traffic"
ct state invalid drop comment "Drop invalid connections"
icmp type echo-request limit rate over 10/second burst 4 packets drop comment "No ping floods"
icmpv6 type echo-request limit rate over 10/second burst 4 packets drop comment "No ping floods"
ct state established,related accept comment "Accept traffic originated from us"
icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem, echo-request, mld-listener-query, mld-listener-report, mld-listener-done, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, ind-neighbor-solicit, ind-neighbor-advert, mld2-listener-report } accept comment "Accept ICMPv6"
icmp type { destination-unreachable, echo-request, router-advertisement, router-solicitation, time-exceeded, parameter-problem } accept comment "Accept ICMP"
ip protocol igmp accept comment "Accept IGMP"
ip protocol tcp limit rate 10/minute burst 5 packets counter packets 480722 bytes 23591287 log prefix "tcp.in.dropped: "
ip protocol udp limit rate 10/minute burst 5 packets counter packets 455080 bytes 37039917 log prefix "udp.in.dropped: "
}
chain my_forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept comment "Accept traffic originated from us"
meta l4proto tcp counter packets 15365827 bytes 939912442 flow add @f
meta l4proto udp counter packets 7421249 bytes 592437585 flow add @f
ip protocol tcp limit rate 5/minute burst 5 packets counter packets 13431 bytes 698736 log prefix "tcp.forward.dropped: "
ip protocol udp limit rate 5/minute burst 5 packets counter packets 320579 bytes 24855150 log prefix "udp.forward.dropped: "
}
chain my_output {
type filter hook output priority filter; policy accept;
}
}
Où :
- “f” est le nom donné à notre flowtable.
- Dans certaines lignes, par ex. ligne 104, on appelle “f” avec “@f”.
- Dans cet exemple, on dit donc à flowtable d'accélérer les paquets tcp et udp si possible
- Le meta l4proto permet de gérer à la fois ipv4 et ipv6
La conséquence, c'est que dans conntrack :
- snippet.bash
udp 17 src=45.134.212.98 dst=80.67.191.2 sport=6890 dport=29350 [UNREPLIED] src=10.12.20.39 dst=45.134.212.98 sport=29350 dport=6890 [OFFLOAD] mark=0 use=2
Où : - “Offload” indique que le paquet a utilisé le circuit court.
C'est appliqué dans le cas du foward et pas du input, car c'est pertinent en foward. C'est là qu'on a le plus de trafic. Si on l'appliquait à input, cela ne changerait pas grand chose - mais on pourrait.
Exemple de la VM Edge
L'intérêt de tout ça ?
Cette VM n'a pas encore flowtable. Voyons comment c'est configuré :
# cat /etc/nftables.conf
!/usr/sbin/nft -f
flush ruleset
# On crée une première table inet, ce qui signifie qu'on va traiter des paquets réseaux
table inet my_table {
# On donne un alias sur deux set d'IP (v4 et v6)
set ipv4_local_addr {
# Le type de l'IP (v4 ou v6)
type ipv4_addr
# Ici ce n'est pas pertinent, mais cela permet d'ajouter des IPs au fil de l'eau
flags interval
elements = {
10.0.10.200,
169.254.0.200,
80.67.181.0,
62.112.29.67,
127.0.0.0/8
}
}
set ipv6_local_addr {
type ipv6_addr
flags interval
elements = {
2001:913:1000:10::200,
fe80:cafe::200,
2001:913:1000:100::200,
2a00:1528:3201:5::22,
::1
}
}
# Les chain sont des endroits particuliers où on va pouvoir appliquer certains types de règles. C'est toute la partie entre ingress et egress. Le cas est atypique dans Neutrinet : on dit que les IP qi sont les nôtres ne sont pas trackées.
chain my_prerouting {
# On est dans la partie prerouting et on accepte tout par défaut
type filter hook prerouting priority raw; policy accept;
# Les IP internes à Neutrinet on les acceptes et on s'arrête
ip daddr @ipv4_local_addr accept
ip6 daddr @ipv6_local_addr accept
# Tout le reste on ne les track pas
# Cela veut dire qu'on ne fait que du forward sans appliquer de règles de firewall, et donc le kernel fait vraiment le minimum (on désactive en quelque sorte netfilter)
# La raison, c'est que cette VM doit faire passe-plat pour les IP de nos membres, donc on désactive un maximum de trucs
notrack
}
chain my_input {
# On est dans la partie input et par défaut on drop tout
type filter hook input priority 0; policy drop;
# iif veut dire "input interface" (pour "output interface", c'est oif). Si elle n'existe pas, nftables va râler. Il existe une directive qui permet d'utiliser iif ou oif si l'interface n'existe pas encore.
# lo et routing ce sont les interfaces de loopback, donc on accepte tout car c'est la communication interne à la VM
iif lo accept comment "Accept any localhost traffic"
iif routing accept comment "Accept any localhost traffic"
# ct = connection tracking
# on drop tout ce qui est invalide
ct state invalid drop comment "Drop invalid connections"
# et on accepte déjà toutes les connexions qu'on avait déjà commencé et qui sont encore en cours (c'est une optimisation)
ct state established,related accept comment "Accept traffic originated from us"
# Limit ping requests. Il y a plein de types dans icmp, et nous on veut juste permettre de pinguer les IP de la VM (puisqu'on est dans input)
ip protocol icmp icmp type echo-request limit rate over 1/second burst 5 packets drop
ip6 nexthdr icmpv6 icmpv6 type echo-request limit rate over 1/second burst 5 packets drop
# On enlève plein de paquets qu'on n'est pas censés recevoir et qui doivent donc être considérés comme invalides
# Drop all fragments.
ip frag-off & 0x1fff != 0 counter drop
# Force SYN checks.
tcp flags & (fin|syn|rst|ack) != syn ct state new counter drop
# Drop XMAS packets.
tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg counter drop
# Drop NULL packets.
tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 counter drop
# On accepte plein de grands classiques du réseau
# Allow certain inbound ICMP types (ping, traceroute).
# With these allowed you are a good network citizen.
ip protocol icmp icmp type { destination-unreachable, echo-reply, echo-request, source-quench, time-exceeded } accept
# Without the nd-* ones ipv6 will not work.
ip6 nexthdr icmpv6 icmpv6 type { destination-unreachable, echo-reply, echo-request, nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert, packet-too-big, parameter-problem, time-exceeded } accept
# Allow IPv6 multicast listener discovery on link-local
ip6 nexthdr icmpv6 icmpv6 type {mld-listener-query, mld-listener-report, mld-listener-reduction, mld2-listener-report } ip6 saddr fe80::/10 accept
# Cette règle ne marche pas, mais l'idée était de permettre en UDP certains ports pour le traceroute (sinon on a des petites étoiles et c'est triste)
udp dport 33434-33523 accept comment "Accept Tracroute"
# On permet à librenms d'accéder à la VM en snmp
# saddr = source addresse
# dport = destination port
# Ici snmp est un protocole connu de nftables, mais sinon il faut mettre le numéro du port
udp dport snmp ip saddr 10.0.11.109 accept comment "Accept SNMP on port snmp"
udp dport snmp ip6 saddr 2001:913:1000:11::109 accept comment "Accept SNMP on port snmp"
tcp dport ssh accept comment "Accept SSH on port 22"
# iifname = c'est la fameuse directive qui permet de dire que si l'interface n'existe pas, on peut quand même la définir dans nftables (qui va créer la règle dans le kernel)
# Donc ici on accepte sur certaines interfaces de parler en BGP sur certaines ip destination
# Cela permet de limiter le plus possible qui peut nous parler en BGP
# Les IP ce sont celles portées par la VM, c'est pour ça que ce sont celles de destination
tcp dport bgp iifname "ens20" ip6 daddr {2a00:1528:3201:5::22} accept comment "Accept BGP on port 179"
tcp dport bgp iifname "ens20" ip daddr {62.112.29.67} accept comment "Accept BGP on port 179"
tcp dport bgp iifname "ens19" ip6 daddr {fe80:cafe::200} accept comment "Accept BGP on port 179"
udp dport 3784 iifname "ens20" ip6 daddr {2a00:1528:3201:5::22} accept comment "Accept BFD on port 3784"
udp dport 3784 iifname "ens20" ip daddr {62.112.29.67} accept comment "Accept BFD on port 3784"
udp dport 3784 iifname "ens19" ip6 daddr {fe80:cafe::200} accept comment "Accept BFD on port 3784"
# Customization des logs et permet d'avoir un compteur de paquets
log prefix "[nftables] Input Denied: " counter drop
}
chain my_forward {
# On est dans la partie forward, qui est après le routing. On drop tout par défaut.
type filter hook forward priority 0; policy drop;
# Ici on utilise routing parce qu'on est dans un VRF (Virtual routing forward, voir glossaire). Sinon, "routing" est une interface de loopback comme vu plus haut.
# Normalement on aurait mis des interfaces physiques (ens19 et ens20 pour l'input interface)
# Mais ici, on reste dans le VRF et donc on est toujours dans la loopback routing
iifname "routing" oifname "ens19" accept comment "Accept Internet to Neutrinet"
iifname "routing" oifname "ens20" accept comment "Accept Neutrinet to Internet"
log prefix "[nftables] Forward Denied: " counter drop
}
chain my_output {
# On est dans la partie output et on accepte tout.
type filter hook output priority 0; policy accept;
}
}
Pour lister les règles de firewall:
nft list ruleset
Une autre manière de faire, c'est ce qui se fait chez GrapheneOS (sur leur infra).
chain output-raw {
type filter hook output priority raw
oif lo goto output-raw-loopback
# Ce n'est pas un poisson.
# Si uid des utilisateurs n'est pas dans la liste définie (root, etc.), pas d'accès à internet, on drop le paquet, mais poliment.
# Ça, on peut pas le faire avec iptables
skuid != { root, systemd-network, unbound, alpm, chrony, postfix, dovecot, dovenull, http } counter goto graceful-reject
# translate DSCP to priority for fq bands
meta priority set ip dscp map @dscp-to-priority
meta priority set ip6 dscp map @dscp-to-priority
meta l4proto { icmp, ipv6-icmp } notrack accept
}
Un exemple d'une boite internet fournie par NeutriCorp dans une occupation de sans papiers:
Ici, on fait du flowtable - hardware, ce qui permet d'aller encore plus vite. Parce qu'on a des instructions hardware pour flowtable. Beaucoup de règles ne sont pas visibles, elles sont inclues dans OpenWRT, et ce n'est pas quelque chose à quoi on est sensé toucher.
En fait, Tharyrok n'a rien fait. Il a juste cliqué sur un bouton dans Openwrt pour activer flowtables et la fonctionnalité hardware. C'est un charlatan.
table inet fw4 {
flowtable ft {
hook ingress priority filter
devices = { lan1, lan2, lan3, lan4, pppoe-wan, wan }
flags offload
counter
}
chain input {
type filter hook input priority filter; policy drop;
iif "lo" accept comment "!fw4: Accept traffic from loopback"
ct state vmap { established : accept, related : accept } comment "!fw4: Handle inbound flows"
tcp flags & (fin | syn | rst | ack) == syn jump syn_flood comment "!fw4: Rate limit TCP syn packets"
iifname "br-lan" jump input_lan comment "!fw4: Handle lan IPv4/IPv6 input traffic"
iifname "pppoe-wan" jump input_wan comment "!fw4: Handle wan IPv4/IPv6 input traffic"
jump handle_reject
}
chain forward {
type filter hook forward priority filter; policy drop;
meta l4proto { tcp, udp } flow add @ft
ct state vmap { established : accept, related : accept } comment "!fw4: Handle forwarded flows"
iifname "br-lan" jump forward_lan comment "!fw4: Handle lan IPv4/IPv6 forward traffic"
iifname "pppoe-wan" jump forward_wan comment "!fw4: Handle wan IPv4/IPv6 forward traffic"
jump handle_reject
}
chain output {
type filter hook output priority filter; policy accept;
oif "lo" accept comment "!fw4: Accept traffic towards loopback"
ct state vmap { established : accept, related : accept } comment "!fw4: Handle outbound flows"
oifname "br-lan" jump output_lan comment "!fw4: Handle lan IPv4/IPv6 output traffic"
oifname "pppoe-wan" jump output_wan comment "!fw4: Handle wan IPv4/IPv6 output traffic"
}
chain prerouting {
type filter hook prerouting priority filter; policy accept;
iifname "br-lan" jump helper_lan comment "!fw4: Handle lan IPv4/IPv6 helper assignment"
}
chain handle_reject {
meta l4proto tcp reject with tcp reset comment "!fw4: Reject TCP traffic"
reject comment "!fw4: Reject any other traffic"
}
chain syn_flood {
limit rate 25/second burst 50 packets return comment "!fw4: Accept SYN packets below rate-limit"
drop comment "!fw4: Drop excess packets"
}
chain input_lan {
jump accept_from_lan
}
chain output_lan {
jump accept_to_lan
}
chain forward_lan {
jump accept_to_wan comment "!fw4: Accept lan to wan forwarding"
jump accept_to_lan
}
chain helper_lan {
}
chain accept_from_lan {
iifname "br-lan" counter packets 1004587 bytes 1443831784 accept comment "!fw4: accept lan IPv4/IPv6 traffic"
}
chain accept_to_lan {
oifname "br-lan" counter packets 154610 bytes 11048356 accept comment "!fw4: accept lan IPv4/IPv6 traffic"
}
chain input_wan {
meta nfproto ipv4 udp dport 68 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCP-Renew"
icmp type echo-request counter packets 3698 bytes 254685 accept comment "!fw4: Allow-Ping"
meta nfproto ipv4 meta l4proto igmp counter packets 0 bytes 0 accept comment "!fw4: Allow-IGMP"
meta nfproto ipv6 udp dport 546 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCPv6"
ip6 saddr fe80::/10 icmpv6 type . icmpv6 code { mld-listener-query . 0, mld-listener-report . 0, mld-listener-done . 0, mld2-listener-report . 0 } counter packets 0 bytes 0 accept comment "!fw4: Allow-MLD"
icmpv6 type { destination-unreachable, time-exceeded, echo-request, echo-reply, nd-router-solicit, nd-router-advert } limit rate 1000/second burst 5 packets counter packets 6754 bytes 381368 accept comment "!fw4: Allow-ICMPv6-Input"
icmpv6 type . icmpv6 code { packet-too-big . 0, parameter-problem . 0, nd-neighbor-solicit . 0, nd-neighbor-advert . 0, parameter-problem . 1 } limit rate 1000/second burst 5 packets counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Input"
tcp dport 5049 counter packets 6 bytes 360 accept comment "!fw4: tharyrok tmp ssh"
jump reject_from_wan
}
chain output_wan {
jump accept_to_wan
}
chain forward_wan {
icmpv6 type { destination-unreachable, time-exceeded, echo-request, echo-reply } limit rate 1000/second burst 5 packets counter packets 121 bytes 9272 accept comment "!fw4: Allow-ICMPv6-Forward"
icmpv6 type . icmpv6 code { packet-too-big . 0, parameter-problem . 0, parameter-problem . 1 } limit rate 1000/second burst 5 packets counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Forward"
meta l4proto esp counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: Allow-IPSec-ESP"
udp dport 500 counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: Allow-ISAKMP"
jump reject_to_wan
}
chain accept_to_wan {
meta nfproto ipv4 oifname "pppoe-wan" ct state invalid counter packets 27115 bytes 1305143 drop comment "!fw4: Prevent NAT leakage"
oifname "pppoe-wan" counter packets 430674 bytes 159292423 accept comment "!fw4: accept wan IPv4/IPv6 traffic"
}
chain reject_from_wan {
iifname "pppoe-wan" counter packets 18310 bytes 5381220 jump handle_reject comment "!fw4: reject wan IPv4/IPv6 traffic"
}
chain reject_to_wan {
oifname "pppoe-wan" counter packets 0 bytes 0 jump handle_reject comment "!fw4: reject wan IPv4/IPv6 traffic"
}
chain dstnat {
type nat hook prerouting priority dstnat; policy accept;
}
chain srcnat {
type nat hook postrouting priority srcnat; policy accept;
oifname "pppoe-wan" jump srcnat_wan comment "!fw4: Handle wan IPv4/IPv6 srcnat traffic"
}
chain srcnat_wan {
meta nfproto ipv4 masquerade comment "!fw4: Masquerade IPv4 wan traffic"
}
chain raw_prerouting {
type filter hook prerouting priority raw; policy accept;
}
chain raw_output {
type filter hook output priority raw; policy accept;
}
chain mangle_prerouting {
type filter hook prerouting priority mangle; policy accept;
}
chain mangle_postrouting {
type filter hook postrouting priority mangle; policy accept;
oifname "pppoe-wan" tcp flags & (fin | syn | rst) == syn tcp option maxseg size set rt mtu comment "!fw4: Zone wan IPv4/IPv6 egress MTU fixing"
}
chain mangle_input {
type filter hook input priority mangle; policy accept;
}
chain mangle_output {
type route hook output priority mangle; policy accept;
}
chain mangle_forward {
type filter hook forward priority mangle; policy accept;
iifname "pppoe-wan" tcp flags & (fin | syn | rst) == syn tcp option maxseg size set rt mtu comment "!fw4: Zone wan IPv4/IPv6 ingress MTU fixing"
}
}
Ca se configure dans Network → Firewall → Routing/NAT Offloading → Hardware offloading. Attention, si ce n'est pas supporté on est bon pour reset le routeur.
On a le choix entre hardware et software (software est toujours supporté).
Cluster Patata
Proposition : chaque machine reçoit une IPv4 en /32, ça veut dire que toute la communication doit passer par le pfSense. Pour l'IPv6, l'idée est que pfSense forward et que ce soit géré par nftable dans les VM. Ce que cela apporte, c'est que quand les VM doivent parler entre elles par leurs IP publics - le mail par ex. - c'est compliqué. Cela fait beaucoup d'entrées dans pfSense.
Le fait que les VM parlent différemment entre elles simplifierait :
Cela permet de limiter quelles VMs doivent contacter quelles VMs Cela permet de buter l'IPv4 le plus possible. Cela simplifie les règles firewall côté pfSense.
Mais ça veut dire que pour ouvrir un port, il faut ouvrir le port sur la VM, et faire une redirection dans PfSense (si l'on veut que ce soit public). Il faudra s'en souvenir.
Si on ne veut pas que ce soit public, il faut limiter en IPv6 la source (par exemple on dit que seul haproxy peut parler à notre VM sur ce port)
On ne pourra pas mettre le nom d'hôte de la VM, parce que même si nftables sait faire la résolution dns, il va se casser la figure au démarrage. Donc il faudra bien prendre le pli d'indiquer en commentaire à quoi correspond l'IP.
Une config de Tharyrok (pas chez Neutrinet) :
- snippet.bash
/etc/nftables.conf /etc/nftables.d/ |-- input | |-- 10-ssh.nft | `-- 20-haproxy.nft `- nat-v4
Pour Haproxy, on autorise les ports web, en udp aussi pour HTTP/3
- snippet.bash
root@haproxy:/home/tharyrok# cat /etc/nftables.d/input/20-haproxy.nft ip saddr {0.0.0.0/0} tcp dport {80, 443} accept comment "Accept haproxy" ip saddr {0.0.0.0/0} udp dport {80, 443} accept comment "Accept haproxy" ip6 saddr {::/0} tcp dport {80, 443} accept comment "Accept haproxy" ip6 saddr {::/0} udp dport {80, 443} accept comment "Accept haproxy"
On peut inclure des fichiers nftables, donc pour l'ouverture de port ça pourrait être assez simple:
- snippet.bash
root@haproxy:/home/tharyrok# cat /etc/nftables.conf #!/usr/sbin/nft -f flush ruleset table inet my_table { chain my_input { type filter hook input priority 0 policy drop include "/etc/nftables.d/input/*.nft" ip protocol tcp limit rate 10/minute counter log prefix "tcp.in.dropped: " ip protocol udp limit rate 10/minute counter log prefix "udp.in.dropped: " } }
Pour un service web, on ouvre le port 8443 que pour haproxy :
- snippet.bash
root@mpd:/home/tharyrok# cat /etc/nftables.d/input/20-mympd.nft ip6 saddr {2001:913:1d00:102::21} tcp dport 8443 accept comment "Accept mympd"
Prochaine réunion
Neutriton à planifier en 2026 : - Netbox - SIP / VOIP
Prochaines réunions:
- Hub infra : 31/3 à 18h30 à la Maison de la Paix
- Neutriton mise a jours : 10h30 le 04/04 au Monolith (chez Tharyrok)
Lieu : Maison de la Paix
Garde-Pad : Tharyrok
Météo de fin
Moment informel durant lequel on exprime en peu de mots comment, à titre personnel, la réunion a été vécue que ce soit positif ou négatif. Si une ou plusieurs tension est née durant la réunion, il est peut-être nécessaire d'envisager l'une ou l'autre réunion pour y remédier.