banquise/infrastructure

Fork 0

Routeur #10

New issue

Open

opened 2026-03-13 20:08:15 +01:00 by mickael.razzouk · 6 comments

mickael.razzouk commented

2026-03-13 20:08:15 +01:00

Owner

Le but est de choisir un routeur qui répond a nos besoin :

declaratif, fini les skill issues
linux based, fini les bsd issues
stable, sinon c est infernal de travailler et sa demotive
accesible et simple, quite a etre plus basique.

Le but est de choisir un routeur qui répond a nos besoin : - declaratif, fini les skill issues - linux based, fini les bsd issues - stable, sinon c est infernal de travailler et sa demotive - accesible et simple, quite a etre plus basique.

mickael.razzouk commented

2026-03-13 20:09:08 +01:00

Author

Owner

nos options:

debian + ansible
nixos

nos options: - debian + ansible - nixos

mickael.razzouk added this to the INTERNET milestone

2026-03-13 20:09:18 +01:00

mickael.razzouk commented

2026-03-14 17:55:12 +01:00

Author

Owner

On part sur plusieurs choix:

debian pour l os; nix avait l air terrifiant
on conteneurise tout les composants pour etre indépendant des versions des packets debian donc pouvoir rollback
on manage les conteneurs avec systemd pour centraliser la gestion, les logs et le lifecycle
on utilise podman pour les conteneurs parceque c est daemonless donc pas besoin de restart les conteneurs
on utilise nftables pour remplacer iptables : https://www.procustodibus.com/blog/2021/11/wireguard-nftables/

On part sur plusieurs choix: - debian pour l os; nix avait l air terrifiant - on conteneurise tout les composants pour etre indépendant des versions des packets debian donc pouvoir rollback - on manage les conteneurs avec systemd pour centraliser la gestion, les logs et le lifecycle - on utilise podman pour les conteneurs parceque c est daemonless donc pas besoin de restart les conteneurs - on utilise nftables pour remplacer iptables : https://www.procustodibus.com/blog/2021/11/wireguard-nftables/

mickael.razzouk commented

2026-03-14 21:46:39 +01:00

Author

Owner

DHCP & DNS

Si le serv dhcp tombe, les leases expirent et les link entre node tombent.
pour éviter ca on veut des ip statiques sur les machines.
Mais c est chiant de devoir écrire a la main l'ip de chaque machine dans la conf et ca pose problème pour :

suivre quelle machine a quelle ip
faire de la résolution DNS avec le hostname

donc on va faire ça :
quand une machine se connecte pour la première fois, elle demande une lease DHCP, le serveur attribue une ip qui sera une lease statique et la machine la définit comme ip statique des sa première connexion. Les avantages de cette solution sont :

correspondance ip machine centralisée
résolution DNS des hostname possible grasse aux lease dhcp statiques
les machines ne sont pas dépendantes du serveur DHCP et peuvent continuer à communiquer en L2 via le switch même si le routeur est down.

services:
  dnsmasq:
    image: docker.io/dockurr/dnsmasq
    container_name: dnsmasq
    ports:
      - 53:53/udp
      - 53:53/tcp
    cap_add:
      - NET_ADMIN
      - NET_RAW
    volumes:
      - /etc/dnsmasq.conf:/etc/dnsmasq.conf
      - /etc/dnsmasq.d/:/etc/dnsmasq.d/
      - /var/lib/misc/dnsmasq.leases:/var/lib/misc/dnsmasq.leases
    network_mode: host
    restart: always

conf :

dhcp-leasefile=blablabla
interface=enp8s0
dhcp-range=startip,endip,infinite

### DHCP & DNS Si le serv dhcp tombe, les leases expirent et les link entre node tombent. pour éviter ca on veut des ip statiques sur les machines. Mais c est chiant de devoir écrire a la main l'ip de chaque machine dans la conf et ca pose problème pour : - suivre quelle machine a quelle ip - faire de la résolution DNS avec le hostname donc on va faire ça : quand une machine se connecte pour la première fois, elle demande une lease DHCP, le serveur attribue une ip qui sera une lease statique et la machine la définit comme ip statique des sa première connexion. Les avantages de cette solution sont : - correspondance ip machine centralisée - résolution DNS des hostname possible grasse aux lease dhcp statiques - les machines ne sont pas dépendantes du serveur DHCP et peuvent continuer à communiquer en L2 via le switch même si le routeur est down. ``` services: dnsmasq: image: docker.io/dockurr/dnsmasq container_name: dnsmasq ports: - 53:53/udp - 53:53/tcp cap_add: - NET_ADMIN - NET_RAW volumes: - /etc/dnsmasq.conf:/etc/dnsmasq.conf - /etc/dnsmasq.d/:/etc/dnsmasq.d/ - /var/lib/misc/dnsmasq.leases:/var/lib/misc/dnsmasq.leases network_mode: host restart: always ``` conf : - dhcp-leasefile=blablabla - interface=enp8s0 - dhcp-range=startip,endip,infinite

ednxzu commented

2026-03-15 17:36:43 +01:00

Member

No description provided.

schema.png

136 KiB

mickael.razzouk added this to the Refonte de l'infra project

2026-03-15 17:45:39 +01:00

mickael.razzouk commented

2026-03-23 23:50:17 +01:00

Author

Owner

No description provided.

Untitled-2026-03-23-2209.svg

52 KiB

mickael.razzouk commented

2026-03-29 16:49:57 +02:00

Author

Owner

@thomas.le-magoariec
Conditions pour le DHCP:

possibilité d’intégrer avec dns pour resolv les hostnames
- https://www.rfc-editor.org/rfc/rfc2136
ip unique par mac address
possible de save la db de lease
conteneurisable

@thomas.le-magoariec Conditions pour le DHCP: - possibilité d’intégrer avec dns pour resolv les hostnames - https://www.rfc-editor.org/rfc/rfc2136 - ip unique par mac address - possible de save la db de lease - conteneurisable