Auteur Sujet: Dégager la freebox serveur: routeur, wifi,firewall, ... que me conseillez-vous ? (Lu 13741 fois)

nouknouk · « **Réponse #12 le:** 23 février 2021 à 03:07:34 »

remarque du soir, bonsoir : j'ai un Switch (tp-link 24 ports) manageable.

Si je l'intercale entre mon MC 220L et le port WAN de mon nanopi, est-ce que je pourrais m'en servir pour 'détagguer' le vlan 836 et résoudre mon souci de promiscuous mode ?

clecle226 · « **Réponse #13 le:** 23 février 2021 à 08:20:24 »

C’est bon j’ai trouvé ^^

à la ligne 130, tu remplaces

Code: [Sélectionner]

proto_add_ipv4_route "0.0.0.0" 0par

Code: [Sélectionner]

[ ! -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && proto_add_ipv4_route "0.0.0.0" 0
C'est le code pour rajouter la route par défaut.
Du coup, il crée l’interface, mais ne se route pas dessus lorsqu’il s’agit de l’interface 1/4 d’IP^^ (et les logs ont cessé aussi)

Tu supprimes aussi

Code: [Sélectionner]

[ -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && exit 1 du coup.

nouknouk · « **Réponse #14 le:** 23 février 2021 à 21:40:28 »

Ca fonctionne comme un charme !

IPv full stack en place, débit ok et CPU en idle qui se tourne les pouces.

Il me reste mon souci de besoin du promiscuous mode sur l'interface WAN, sur lequel je vais me concentrer désormais:

- les NIC côté WAN et LAN sont deux modèles différents sur le NanoPI R4S ; je vais tenter d'intervertir LAN et WAN pour voir si c'est bien le support du chip ethernet côté WAN qui pose problème (ou si c'est autre chose).

- ou il faudra sans doute que je creuse l'idée de dé-tag le vlan 836 grâce à mon switch manageable

- et dans le pire des cas, en dernier ressort, il me reste le workaround d'activer le promiscuous mode au démarrage du routeur.

Merci beaucopu en attendant pour ta patience et ton aide préciseuse !

nouknouk · « **Réponse #15 le:** 23 février 2021 à 23:13:15 »

je ne résiste pas à un petit screenshot qui montre la conso électrique de mon armoire réseau :
- avant, avec la Freebox révolution
- après, avec le nanopi r4s + le TPLink MC-220L

doctorrock · « **Réponse #16 le:** 23 février 2021 à 23:15:42 »

T'as gagné 25W à peu près c'est ça ? Pas mal ^^

nouknouk · « **Réponse #17 le:** 24 février 2021 à 00:19:26 »

A la grosse louche, oui.
Je dirais plutôt dans les 20w.

(my life ON)

Le nanopi en a clairement encore sous la pédale.

Mon petit bench perso à sa réception, c'est un truc classique que je tente a chaque nouveau matos qui arrive à la maison: j'installe le logiciel 'motion' (détection de mouvement sur flux vidéo), je lui envoie le flux de mes 5 caméras FullHD (de surveillance de la maison), et je regarde la charge CPU.
J'ai de l'atom z8530, du rpi3, 4, etc... qui sont passés à la casserole. Le nanopi r4s est un des rares à s'en sortir sans rougir, le tout pour moins de 5w de diff idle/charge quand mon J4105 (serveur a tout faire de référence dans la baie) prend plus de 10w pour ma même chose.

Bref, la phase 2 c'est ajouter les services et config 'réseau': wireguard, upnp, ... Que la Freebox gérait jusque là.

Phase 2b, ajouter le services qui me manquent encore: splitting du réseau maison en vlan (+ AP Xiaomi wifi sous openwrt), dnsd, ntpd, mails pour mon domaine, contrôle parental sur les subnets des enfants, ...

Phase 3, c'est finir de déporter les services restants sur ce nanopi (ou un frère jumeau), suffisamment pour pouvoir laisser eteint mon j4105 'principal' 95% du temps et gagner encore 15-20w de conso.

Le reste niveau conso ne pourra pas descendre plus bas: AP WiFi et les cams alimentés depuis la baie en PoE, Switch, ...

(my life OFF)

nouknouk · « **Réponse #18 le:** 27 février 2021 à 14:40:54 »

Mon routeur NanoPi R4S + openwrt tourne désormais depuis plusieurs jours à la maison.
Je fais face à un problème persistant pour du surf HTTP(s):

- j'ouvre un site 'nouveau' (=domaine pas visité récemment) dans mon navigateur => la page ne charge jamais (status reste bloqué en 'opening socket' sous w3m)
- un simple 'F5' pour relancer le chargement => le site se charge bien.
- tant que je continue à naviguer sur ce site ou que j'y accède à intervalles réguliers, tout es ok.
- si je ne vais plus sur ce site pendant un certain temps (plusieurs minutes) et que j'y retourne => rebelote
- si je suis sur le site (ok), je reboote openwrt, je retente dans la foulée (= sans attendre plusieurs minutes) => le problème réapparaît.

J'ai fait des captures wireshark dans les deux cas (success / failure) avec un setup:
- machine desktop (192.168.0.2) qui est celle qui fait tourner wireshark
- la machine desktop browse (via w3m) https://developpez.com (87.98.130.52)
- la machine desktop est derrière mon nanoPI qui fait le NAT + routing (LAN=192.168.0.254) vers le WAN.

- en cas de failure (= la page ne se charge jamais), je vois passer, cf. screenshot #1
* une requête DNS pour résoudre developpez.com + sa réponse
* une ouverture du canal TCP pour le HTTPS
* un 'client Hello' (handshake SSL ?) + l'ACK TCP
* puis du "TCP previous segment not captured]", puis plus rien.

- en cas de succès (= la page se charge bien), je vois passer, cf. screenshot #2
* une requête DNS pour résoudre developpez.com + sa réponse
* une ouverture du canal TCP pour le HTTPS
* un 'client Hello' (handshake SSL ?) + l'ACK TCP
* le 'Server Hello', et le tout le reste qui déroule normalement.

=> une idée de l'origine du souci ?

clecle226 · « **Réponse #19 le:** 27 février 2021 à 16:42:55 »

… Bizarre… le premier truc qui me saute aux yeux, c’est la différence de protocole TLS… TLSv1 quand ça marche pas et TLSv1.3 quand ça marche…
Aujourd’hui c’est très rare les sites qui accepte du TLSv1 (et ça continue de disparaitre presque totalement)
– Tu as testé/remarqué le même genre de problème sur les sites en HTTP only? (monip.org)

Car je trouve ça bizarre que le routeur soit fautif étant donné qu’il ne fait que router les paquets (à moins qu’il y a ait un MITM dans ton réseau).
Et le TLSv1 me fait penser à une tentative de downgrade de la sécurité par un MITM … mais sur un réseau familial, c’est plutôt rare (et c’est un euphémisme)…

De plus, pour de ce que tu décris du problème: On est pas sur un cas de problème DNS. On est vraiment sur un cas où tant que la session TLS est active, pas de problème, mais la renégociation de clé poserai problème... ...

Mais par contre... la session TLS ne devrait pas être influencer par un reboot du routeur... ... ... du, coup ....

$:-\$

nouknouk · « **Réponse #20 le:** 27 février 2021 à 17:19:11 »

Re,

merci pour ton retour.

Citation de: clecle226 le 27 février 2021 à 16:42:55

On est vraiment sur un cas où tant que la session TLS est active, pas de problème, mais la renégociation de clé poserai problème... ...

Je me suis sans doute mal exprimé, mais mon souci n'est pas: "je me connecte au site, ça fonctionne quelque temps et au bout d'un moment, connexion perdue" ; le souci se pose en début de connexion vers le site.

Plusieurs essais plus tard, il semblerait que j'ai quelque chose qui fonctionne en baissant le MTU de mes deux interfaces wan6 & wan (cf. screenshot #1)

Code: [Sélectionner]

config interface 'wan'
	option ifname 'eth0.836'
	option tunlink 'wan6'
	option proto 'map'
...
        option mtu '1200'  # au lieu de 1500 précédemment
...
config interface 'wan6'
        option ifname 'eth0.836'
...
        option mtu '1460'  # au lieu de 1700 précédemment
...

Ca me donne ça (eth0 = WAN ; eth1 = LAN):

Code: [Sélectionner]

root@OpenWrt:~# ip addr | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
3: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
6: eth0.836@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default qlen 1000
7: map-wan@eth0.836: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1200 qdisc noqueue state UNKNOWN group default qlen 1000
8: map-wan6_4@eth0.836: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000

J'ai testé la baisse du MTU sans conviction en voyant passer le flag TCP don't fragment dans la réponse "Server Hello" d'une connexion qui fonctionnait (cf. screenshot #2).

Je manque de connaissances à ce niveau pour comprendre le pourquoi du comment et encore plus faire le tour de la question.

- est-ce bien un souci de config de MTU ?

- dans ce cas, pourquoi ça ne marcherait pas à la première tentative et ça serait ok la seconde ?

- si de ton côté ça passe bien avec 1700 / 1500, dois-je en déduire que la vraie root cause serait du côté d'un second souci avec le driver de mon interface WAN (en plus de l'histoire du promiscuous mode que je dois forcer) ?

- et si c'est bien la root cause, quelles seraient les meilleurs valeurs à adopter ?

- enfin le TLSv1 auquel je n'ai pas de réponse non plus (ou 1ère tentative en TLS 1.3 et seconde en 1.0 ?)

Bref, encore beaucoup de flou, et j'avoue que je n'aime pas trop ne pas comprendre ce qui se trame derrière tout ça...

EDIT: le TLS dans le cas d'une connexion qui fail semble être du 1.2 (cf. screensho #3) (je ne sais pas si ça change grand chose)

clecle226 · « **Réponse #21 le:** 27 février 2021 à 17:33:49 »

Si c’est le MTU, tu peux aussi débloquer la valeur (les enlevé dans la config) et laisser faire le routeur.
Il y a juste un risque que le débit soit un peu plus faible pour l’IPv4, car le MTU du tunnel sera toujours plus faible que le MTU du lien IPv6.

Et comme par défaut openwrt, mets le MTU à 1500. tu auras un MTU d’IPv4 inférieur à 1500.

Mais un problème de MTU trop grand.... c’est rare... (c’est plutôt l’inverse en général)
Mais si c’est le problème du mode de promiscuité, je sais pas.
EDIT:Ouai non du coup, ça n’a rien à voir avec TLS... c’est juste Wireshark qui affiche pas la bonne valeur dans la liste des paquets, mais il semble pas avoir quoi que se soit de bizarre en soi.

nouknouk · « **Réponse #22 le:** 27 février 2021 à 17:44:28 »

Je pense que je l'ai: le MTU à 1700 de ma config ne semble pas être pris en compte ; il reste à 1500 ; et avec 1500 également côté IPv4, j'imagine que ça fait 'paf le chien'

En remettant la config 1700/1500 (et en reproduisant le souci direct après un reboot, btw), j'ai:

6: eth0.836@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

(en entier ça donne)

Code: [Sélectionner]

root@OpenWrt:~# ip addr | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
3: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP group default qlen 1000
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
6: eth0.836@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
7: map-wan@eth0.836: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
8: map-wan6_4@eth0.836: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000

=> conclusion ?
- encore un souci de mon driver côté WAN qui prend pas en compte le "set MTU" ? (*)
- et pourquoi ça raterait à la première tentative de connexion, mais ça fonctionnerait à la deuxième ?

(*) ou il faudrait que je fasse le changement de MTU sur eth0 plutôt que eth0.836 ? J'ai bien tenté:

Code: [Sélectionner]

ifconfig eth0.836 down && ifconfig eth0 down && ifconfig eth0 mtu 1700

mais j'ai une erreur: "ifconfig: SIOCSIFMTU: Invalid argument"

nouknouk · « **Réponse #23 le:** 27 février 2021 à 18:30:07 »

Citation de: doctorrock le 23 février 2021 à 23:15:42

T'as gagné 25W à peu près c'est ça ? Pas mal ^^

Petit retour d'xp après quelques jours:
- avant, avec la freebox révolution: ma baie consommait 2.11 kWh par jour
- désormais, avec le nanopi R4S + openwrt: ma baie consomme 1.55 kWh par jour

Soit une différence de conso de 23 Watts entre la freebox révo serveur et le nanoPi R4S (très exactement

)