This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------5e7917237d76c7dc16f6a97bdd813965 Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8
------- 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,
JKB
-----------------------5e7917237d76c7dc16f6a97bdd813965
Content-Type: application/pgp-keys; filename="publickey -
hlarrive@pm.me - 0xE9429B87.asc"; name="publickey -
hlarrive@pm.me - 0xE9429B87.asc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publickey -
hlarrive@pm.me - 0xE9429B87.asc"; name="publickey -
hlarrive@pm.me - 0xE9429B87.asc"
LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQpWZXJzaW9uOiBPcGVuUEdQLmpz IHY0LjEwLjEwDQpDb21tZW50OiBodHRwczovL29wZW5wZ3Bqcy5vcmcNCg0KeGpNRVlGRTFjUllK S3dZQkJBSGFSdzhCQVFkQVpQdDNnYXpDa3R1c2lxZWtoM3JzbDNBS1dJVGlEdVRhDQpaT21kSEJa MG1vek5IMmhzWVhKeWFYWmxRSEJ0TG0xbElEeG9iR0Z5Y21sMlpVQndiUzV0WlQ3Q2p3UVENCkZn b0FJQVVDWUZFMzRRWUxDUWNJQXdJRUZRZ0tBZ1FXQWdFQUFoa0JBaHNEQWg0QkFDRUpFRnZWSk5j dg0KNHZrMEZpRUU2VUtiaDRyMkNEZUg2WUZCVzlVazF5L2krVFFqQ0FEL2EzcENIQUkrbE9qNTR1 TlVTU1NDDQpMMTg2MVBiMjhhazYrYm9Gc3pudUdzQUJBUFVzOHdCcktBdnFnRFZhcVl1V3p3UGNN c2dlYndTSG44RHcNCmp1SDV6VmdPempnRVlGRTFjUklLS3dZQkJBR1hWUUVGQVFFSFFPbDZ3OXNi R1lmZHZOeVVPb3pjcExiZg0KdGluekljK2g1YnEvazFPdU13VUZBd0VJQjhKNEJCZ1dDQUFKQlFK Z1VUZmhBaHNNQUNFSkVGdlZKTmN2DQo0dmswRmlFRTZVS2JoNHIyQ0RlSDZZRkJXOVVrMXkvaStU VGhQQUQ5RlM0WWtwVHRFclY0MU9FMEFpM1gNClIxNlcrT3REa1p3bTZRVTY0VnUzSmJvQkFMMURM QngxRExLRE5kclZhTUZ1NGp4MXBZV0JqTEpVZ0xLeg0Kc2wzM2pETU0NCj01dWlWDQotLS0tLUVO RCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQo= -----------------------5e7917237d76c7dc16f6a97bdd813965--
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail
wnUEARYKAAYFAmK+Rx8AIQkQW9Uk1y/i+TQWIQTpQpuHivYIN4fpgUFb1STX L+L5NEqRAP9JBGVGlsgZ7i1M28gmZHrM27PH4sudh2ZRTQhzplDbHAD9GJMv ph6CVPPNRUU1x72pSsNriKnWKL6CvpwPedoXlgE=
=pSwa
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)