------- Original Message -------
Le jeudi 30 juin 2022 à 08:55, BERTRAND Joël <joel.bertrand@systella.fr> a écrit :
>
>
> Bonjour à tous,
>
Bonjour,
> J'utilise des rPI 3 comme point d'accès WiFi. Cela fonctionne bien,
Moi aussi, il a une bonne portée.
> mais depuis la dernière mise à jour de Debian, il y a comme un problème
> lors du démarrage et je suis contraint de démarrer les services à la
> main. Ça m'amuse cinq minutes, pas plus... :-(
>
Pour en revenir à systemd, c'est bien pour les stations de travail,
beaucoup moins pour les serveurs ou l'embarqué. Mon pi3 est en
Debian Systemd/Linux (buster), mais maintenant je préfère Devuan pour
ce genre d'application. C'est un fork de Debian qui offre le choix
entre 3 systèmes d'init :
- le traditionnel sysvinit ;
- openrc (Gentoo) ;
- runit (void linux).
Il est possible de migrer une debian vers devuan, la procédure est sur
le site. Il y a un moment ou apt "couine" un peu, mais ça passe en
insistant un chouya, je l'ai déjà fait trois fois, dont 2 directement
de debian 9 vers devuan chimaera (debian 11).
Les avantages sont :
- un démarrage séquentiel (clarté de la console et des journaux) ;
- une description claire du démarrage dans /etc/rc* ;
- pas de "merged /usr" ;
- pas de renommage des interfaces réseau.
L’inconvénient c'est que l'absence de systemd pose des problèmes pour
les softs qui en dépendent plus ou moins comme lxc...
> Jusqu'ici, ces machines utilisaient un script rc.local qui n'est plus
> appelé. Ce script se terminait pas :
>
Je crois que la commande magique pour qu'il soit de nouveau appelé c'est :
systemctl unmask rc.local.service
C'est pas dit que ça fonctionne, il me semble que dans sysvinit, rc.local
est exécuté tout à la fin donc après networking mais qu'avec systemd
la cible multi utilisateur qui le déclenche est atteinte avant la cible
network...
De toute façon rc.local n'est pas fait pour ça, voir :
https://arkit.co.in/using-rc-local-file-execute-commands/
Il y a trois façons de configurer le réseau sous debian :
- /etc/network/interfaces (historique mais pas encore obsolète) ;
- systemd (moderne...) ;
- network-manager (pour les ordinateurs de bureau / portable).
Je pense que la méthode la mieux adaptée pour un point d'accès sous
debian est /etc/network/interfaces, surtout quand on ne s'en sort
pas avec systemd. C'est la plus éprouvée et la mieux documentée sous
debian.
> rfkill unblock 0
> ifup wlan0
> iptables-legacy -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE
> dhcpd
> exit 0
>
Si rfkill est nuisible, autant le supprimer (apt remove rfkill). Je
n'en vois pas l'utilité sur un point d'accès.
Pourquoi ne pas avoir utilisé /etc/network/interfaces ? Est-il
nécessaire de faire du routage ? Personnellement j'ai préféré
utiliser un pont :
# /etc/network/interfaces
auto lo br0
iface lo inet loopback
iface br0 inet static
address 192.168.1.253/24
gateway 192.168.1.1
pre-up iw dev wlan0 set type __ap
up /etc/nftables.conf
#
# dans /etc/hostapd/hostapd.conf :
bridge=br0
Avec cette configuration on obtient un point d'accès "transparent"
au niveau IP : les périphériques wifi sont sur le même sous-réseau
que l'ethernet, il peuvent recevoir une adresse du DHCP de la
passerelle ou d'un serveur, le point d'accès n'a qu'une seul IP
sur br0. Il n'est pas nécessaire d'activer l'IP forwarding ou de
faire du masquerading avec nftables, il faut juste installer
bridge-utils.
Si on préfère isoler le wifi :
# /etc/network/interfaces
auto lo eth0 wlan0
iface lo inet loopback
iface eth0 inet dhcp
iface wlan0 inet static
address 192.168.11.254/24
pre-up iw dev wlan0 set type __ap
bridge_ports eth0 wlan0
#
Le script (mode 755) /etc/nftables.conf que j'utiliserais :
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0;
}
chain forward {
type filter hook forward priority 0;
}
chain output {
type filter hook output priority 0;
}
chain postrouting {
type nat hook postrouting priority 100; policy accept;
ip saddr 192.168.11.0/24 oifname eth0 masquerade
}
}
#
J'aime bien les scripts nft probablement à cause des accolades
et de l'indentation. Je les trouves plus lisibles que les
scripts iptables qui m'avaient toujours rebuté.
Avec du filtrage et du NAT/PAT (soyez indulgent, je débute en
nft) ça donnerait ce genre de chose :
#!/usr/sbin/nft -f
#
# nettoyage des règles existantes
flush ruleset
define LAN_IF = eth0
define WLAN_IF = wlan0
define WLAN_NET = 192.168.11.0/24
# un serveur en wifi
define WSRV_IP = 192.168.11.1
# table de filtrage ipv4
table inet filter {
chain output {
# le trafic sortant est autorisé par défaut
type filter hook output priority 0; policy accept;
}
chain inbound {
# le trafic entrant est rejeté par défaut
type filter hook input priority 0; policy drop;
# accepter les réponses
ct state { established, related } accept
ct state invalid drop
# tout accepter pour localhost
iifname lo accept
# règles définies en fontion de l'interface
iifname $LAN_IF jump inbound_lan
iifname $WLAN_IF jump inbound_wlan
}
chain inbound_lan {
# règles pour le trafic entrant sur l'interface lan
icmp type echo-request accept
tcp dport ssh accept
}
chain inbound_wlan {
# règles pour le trafic entrant sur l'interface wlan
icmp type echo-request accept
tcp dport ssh accept
}
chain prerouting {
# redirection d'un port de l'interface lan vers un serveur du wlan
# il faudra aussi ajouter une règle dans la chaîne forward pour la réponse
type nat hook prerouting priority -100; policy accept;
# ssh
# avec traduction de port
#iifname $LAN_IF tcp dport 11122 dnat to $WSRV_IP:ssh
# sans traduction de port
#iifname $LAN_IF tcp dport ssh dnat to $WSRV_IP:ssh
## http
#iifname $LAN_IF tcp dport http dnat to $WSRV_IP:http
## ftp
#iifname $LAN_IF tcp dport ftp dnat to $WSRV_IP:ftp
}
chain forward {
# le transfert est rejeté par défaut
type filter hook forward priority 0; policy drop;
# permettre le transfert des requêtes du wlan au lan (masquerading)
iifname $WLAN_IF accept
# permettre les réponses du lan au wlan (masquerading)
ct state { established, related } accept
ct state invalid drop
# autoriser les réponses wlan au lan pour les redirections (dnat)
#ip daddr $WSRV_IP tcp dport ssh accept
## ssh
#ip daddr $WSRV_IP tcp dport ssh accept
## http
#ip daddr $WSRV_IP tcp dport http accept
## ftp
#ip daddr $WSRV_IP tcp dport ftp accept
}
chain postrouting {
# masquerading pour le partage de la connexion internet
type nat hook postrouting priority 100; policy accept;
ip saddr $WLAN_NET oifname $LAN_IF masquerade
}
}
Avec cette configuration seul le point d'accès a une adresse sur
le LAN. Les hôtes wifi peuvent contacter les hôtes du LAN ou la
passerelle mais pas l'inverse sans configurer de dnat.
Voilà, "je pose ça là" comme on dit.
Cordialement,
Hugues
> Aujourd'hui, lorsque je démarre un rPI, je me retrouve avec une
> interface wlan0 qui est bloquée par défaut (soft) :
>
> root@abel:~# rfkill
> ID TYPE DEVICE SOFT HARD
> 0 wlan phy0 blocked unblocked
> 1 bluetooth hci0 blocked unblocked
> root@abel:~#
>
> Là, je ne comprends pas. L'interface est toujours active lors de
> l'extinction et systemd.restore_state vaut par défaut 1.
>
> Si je lance successivement :
>
> rfkill unblock 0
> ifup wlan0
> hostapd -B -P /run/hostapd.pid /etc/hostapd/hostapd.conf
> dhcpd
>
> je récupère une borne WiFi fonctionnelle. J'ai donc écrit dans
> /etc/systemd/system les choses suivantes :
>
> root@abel:/etc/systemd/system# cat rfkill.service
> [Unit]
> Description=rfkill
> Before=ifup@wlan0.service
> After=systemd-rfkill
>
> [Service]
> Type=oneshot
> ExecStart=/usr/sbin/rfkill unblock 0
>
> [Install]
> WantedBy=network.target
>
> root@abel:/etc/systemd/system# cat route.service
> [Unit]
> Description=Wlan route
> After=networking.service
>
> [Service]
> Type=oneshot
> ExecStart=/usr/sbin/iptables-legacy -t nat -A POSTROUTING -s
> 192.168.11.0/24 -j MASQUERADE
>
> [Install]
> WantedBy=network.target
>
> root@abel:/etc/systemd/system# cat dhcpd.service
> [Unit]
> Description=dhcpd
> After=route.service
>
> [Service]
> Type=forking
> ExecStart=/usr/sbin/dhcpd
>
> [Install]
> WantedBy=network.target
>
> Si route.service et dhcpd.service sont appelés, pas moyen que
> rfkill.service soit appelé au bon moment. Il faut pourtant qu'il soit
> appelé après systemd-rfkill (qui merdoie) et avant que l'interface
> wlan0 soit montée par ifup.service. Lors du démarrage, systemd provoque
> un timeout sur rfkill.service et merdoie sur hostapd.service (là, ce
> n'est pas un timeout, mais des lancements de hostapd en boucle parce que
> wlan0 n'existe pas).
>
> Une idée pour corriger la chose, parce que je ne comprends pas trop.
>
> Bien cordialement,
>
> JKBAttachment:
publickey - hlarrive@pm.me - 0xE9429B87.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature