Surveiller ce forum | 
Commencer une nouvelle discussion
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-05-04 10:00 | [forum:495710] |
|
Bonjour, Je reviens avec de bonnes nouvelles, le problème était bien là. Une cinquantaine de personnes connectés en journée et un comportement normal. Merci encore pour ton aide et merci aux développeurs ! |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-23 19:11 | [forum:493451] |
|
Bonjour Monsieur REXY, Je ne pense pas mériter le respect. Le respect revient a Monsieur nOx nOx pour son aide et à vous pour votre énorme travail et ce magnifique logiciel. Bravo à vous ! Et merci pour le temps que vous consacrez à cet outil fortement utile et fortement intéressant ! En plus du logiciel bien ficelé, le fait qu'il soit sous Linux est un +. Et la documentation est un bonheur pour apprendre a installer/exploiter/utiliser le logiciel ! Merci ! |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Richard REY (Rexy) on 2022-04-23 18:42 | [forum:493450] |
|
Bonjour, Je suis bluffé par la qualité de vos investigations. Cela mérite le respect. Bravo. |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-23 17:51 | [forum:493448] |
|
Oui, les différences entre la VM et l'hôte ont disparu. Le problème venait du routeur mais l'hôte fonctionnait et Alcasar aussi depuis SSH. Les ping passait sans problème... Cette histoire de session routeur c'est tellement volatil (de nombreuses sessions s'ouvrent et se ferme rapidement) que un ping passe systématiquement (sur les derniers tests il me semblait bien que les équipements côté consultation continuait à pouvoir pinguer sur le net). Du coup, comme le test de connectivité fonctionne, j'ai accusé à tord Alcasar ; qui lui détectait que les sites web ne répondait pas. Et notamment les sites de vérification de portail (connectivitycheck, detectportal.firefox etc...). C'est pour ça que le navigateur redemander de retourner sur la page de connexion alors que pour Alcasar il était toujours connecté. C'est aussi pour ça que au bout d'un moment, ça revenait et qu'il n'y avais pas besoin de se re-connecter. Comme une connexion a un site internet ouvre parfois de multiples sessions, elles étaient bloqués de manière aléatoire ! Cela refonctionnait certainement dès que la plupart des sessions s'était fermé et que le nombre de session depuis l'IP WAN D'Alcasar passait sous les 1000 sessions.... Maintenant que j'ai régler sur le routeur que Alcasar n'a pas cette limite de 1000 sessions, je n'ai plus eu ces fameuse coupure... Je ne peux désactiver le routage pour faire venir internet directement sur Alcasar. Le routeur gère plusieurs autres VLAN et règles de routage entre ces différents VLAN. |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : nOx nOx on 2022-04-23 12:22 | [forum:493447] |
|
Salut, Désolé j'ai été pris. C'est bien que tu ait trouvé d'ou provient le blocage. Ce que tu peux faire c'est désactiver la fonctionnalité routeur de ton accès internet afin que l'ensemble du routage soit géré par alcasar. Quand ta connexion fail, ce qu'il faut faire, c'es réaliser des teste depuis la VM et depuis ta machine hote. Si ton problème vient du routeur, alors tu devrais voir le même problème depuis l'hote et la VM. En chageant les cartes et en mettant en passthrough tu devrais avoir une émlioration significatives, et les différences entre l'hote et la VM devrait avoir disparu |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-23 11:21 | [forum:493444] |
|
Je pense avoir fini par trouver le problème. Ce n'est pas Alcasar le problème mais mon routeur/pare-feu, qui avait dans ses réglages d'origines une limite de 1000 sessions par client. Ce qui est largement suffisant en temps normal mais trop peu pour Alcasar qui NAT évidemment de nombreux clients.... Difficile a détecter car le ping depuis Alcasar vers Internet passait, même lorsque le pare-feu commençait à bloquer des sessions.... C'est finalement dans les logs du pare-feu (que je n'ai bêtement par inspecter avant) que j'ai trouvé ma solution. J'ai passé Alcasar sans limite de session (sur le pare-feu) et le comportement que j'arrivais à reproduire avec une quinzaine de PC ne c'est pas reproduit avec une bonne vingtaine de poste ce matin ! Je vais valider cette solution cette semaine avec le retour des vacances mais je suis confiant. Merci encore pour ton aide, le fait d'avoir passé sur des cartes Intel I350 et d'être passé en PCI PASSTHROUGH ne peut qu'être bénéfique au vu du nombre de client simultanés que va subir Alcasar. Bon week-end ! |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-22 05:31 | [forum:493421] |
|
Es-ce que ceci est normal (l'adresse en .3 pris par la carte réseau côté consultation : 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 1c:fd:08:75:20:52 brd ff:ff:ff:ff:ff:ff inet 192.168.123.49/24 brd 192.168.123.255 scope global ens3 valid_lft forever preferred_lft forever 3: ens4: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 1c:fd:08:75:20:53 brd ff:ff:ff:ff:ff:ff inet 192.168.182.3/24 brd 192.168.182.255 scope global ens4 valid_lft forever preferred_lft forever 5: tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN group default qlen 100 link/none inet 192.168.182.1/24 scope global tun0 valid_lft forever preferred_lft forever |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-21 21:23 | [forum:493417] |
|
Bonsoir Je reviens un peu désespéré... Je vais redetailler mes observations a partir d'aujourd'hui. Les cartes ont été remplacés par une carte dual-wan (I350 Intel), configurée en PCI passthrough sur le Alcasar. Un test curl pour télécharger un fichier de 10Go ne fait plus de "trous" de connexion. Nouveaux tests : -Bonne performance au départ mais dès qu'il commence à y avoir une dizaine d'utilisateur connectés ça part en sucette... : Ce coup là j'ai pris des postes fixes (une quinzaine) + mon mobile pour observer. Au départ, j'ai laissé le filtrage Blacklist + antivirus et le filtrage de protocole. Postes sous 8.1 avec Firefox + mon pc portable sous Ubuntu + mon mobile sous Android. Utilisateurs de l'LDAP utilisés + 1 utilisateur interne Alcasar pour vérifier que la situation est identique. Symptôme : d'un coup les Firefox, alors qu'ils étaient connectés depuis quelques minutes (et que l'on faisais de la consultation internet pour simuler un usage normal) reaffiche la notification que le réseau a besoin d'une authentification. A ce moment là, parfois des recherches Google étaient possible mais de manière générale plus aucun site n'est accessible. Si on clique sur le lien "Aller a la page de connexion" dans la notification Firefox , on tombe sur la page E2Guardian avec la main Stop disant : detectportal.firefox.com "Site is not responding" avec en bas "Blacklisted User" et l'IP du poste de consultation. Quelques minutes plus tard, ça se débloque, les postes n'ont pas besoin de se loguer a nouveau et la navigation est à nouveau possible. Puis ça revient quelques minutes après.. Environ 3 minutes. Cela se passe sur tous les postes du réseau (et mobile) en même temps. Nous avons ensuite tester beaucoup de choses : - désactiver filtrage URL et protocole : idem - arrêter le service E2Guardian : idem -arreter le service fail2ban : idem -deconnecter physiquement toutes les bornes wifi et ne laisser que ces postes fixes sous Alcasar : idem - passer en mode bypass : alors là on a un comportement similaire, la connexion ne fonctionne plus puis revient toute seule. Sauf que là il n'y avait plus de page E2Guardian. Ça tourne simplement en rond avant de laisser la page d'erreur habituelle Firefox (site non accessible) Pendant les "coupures", un alcasar-watchdog.sh renvois que la connexion est Ok. Dans systemctl status E2Guardian.service, on voit dans les logs "Retry 2 detectportal.firefox.com" (Dans mes precedents tests j'avais aussi eu ça avec connectivitycheck.gstatic.com) On dirait que Alcasar bloque le site de test de portail et que les postes ne se croient plus connecté. Parfois (je n'ai pas pu le reproduire a chaque fois), pendant ses bugs, j'ai tenté la connexion depuis un autre poste (qui n'était pas encore loguer). Firefox affiche le portail captif, valide l'authentification (page status.php) mais ne laisse pas disparaître la notification de connexion. (Et la connexion internet ne fonctionne pas) Merci d'avance pour vos idées ! |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : nOx nOx on 2022-04-10 11:13 | [forum:493215] |
|
Je ne sais pas si c'est Mageia ou si c'est KVM. Ce qui est sûr c'est qu'il y a des comportement étranges sur la gestion du réseau virtualisé. Tu verras bien |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-10 10:32 | [forum:493214] |
|
J'ai commandé une carte Intel pour faire le test, mais je reste étonné d'avoir de meilleurs résultats en mode pont qu'en mode passthrough. Il n'y aurait pas un problème de gestion de la carte Realtek sous Mageia ? J'ai un peu cherché mais je n'ai pas trouvé quoi rajouter ou des pilotes pour essayer d'améliorer la gestion de cette carte. |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : nOx nOx on 2022-04-09 19:14 | [forum:493206] |
|
Sur Alcasar ce qui arcge c'est de ettre les cartes réseau en PCi Passhrouhg. C'est la seule combine pour ne pas avoir de surprise. Ca c'est certain. Je pense que tu as un soucis avec tes canter Realtek, il faudrait essayer avec autre chose. Les cartes que j'utilise (mais il en existe plein d'autres) . Elles intègrent des fonctions de virtualisation matérielles. Intel I350 (https://www.intel.fr/content/www/fr/fr/products/sku/52966/intel-ethernet-controller-i350am4/specifications.html) Intel X710 ( https://www.intel.fr/content/www/fr/fr/products/sku/83965/intel-ethernet-converged-network-adapter-x710da4/specifications.html ) |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-09 17:31 | [forum:493205] |
|
Pour speedtest j'ai trouvé : iptables -P OUTPUT ACCEPT Speedtest by Ookla Server: 31173 Services AB - Paris (id = 39070) ISP: UNYC SAS Latency: 15.43 ms (0.14 ms jitter) Download: 943.66 Mbps (data used: 1.2 GB ) Upload: 472.08 Mbps (data used: 452.0 MB ) Packet Loss: 0.0% Result URL: https://www.speedtest.net/result/c/e183f2b5-eb94-4851-936a-8f5477e142f3 Sur KVM : Speedtest by Ookla Server: Netprotect - Paris (id = 37599) ISP: UNYC SAS Latency: 15.42 ms (0.09 ms jitter) Download: 621.64 Mbps (data used: 1.1 GB ) Upload: 447.67 Mbps (data used: 471.9 MB ) Packet Loss: Not available. Result URL: https://www.speedtest.net/result/c/4f1250f5-8b04-40be-acd8-3ac8c795ae36 |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-09 17:26 | [forum:493204] |
|
Pour résumer, sur le Debian KVM j'ai 4 cartes : - carte mère (2.5GB) : non utilisé - 3 cartes TG-3468 (realtek) : - enp3s0 qui gère les interfaces bridge pour l'ensemble des VM (hors Alcasar) et la connexion du système hôte. - enp4s0 dédié Alcasar WAN - enp5s0 dédié Alcasar LAN Si je fais un test de débit sur Alcasar (je passe donc par enp4s0), j'ai ces fameux trous de connexion. Au même moment, sur ma VM de test (debian avec GNOME), je passe sur le même VLAN que du côté WAN d'Alcasar, je n'ai pas de trous de connexion. Maintenant j'éteins Alcasar et ma VM de test. Je rajoute en mode pci passthrough la carte enp4s0 sur ma vm de test. Je démarre la machine, je fais mon test de débit, et j'ai des trous ! (Malheureusement, je ne peux pas essayer a distance, la même chose avec la carte enp5s0, qui n'est pas relié sur le bon VLAN). Maintenant, je désinstalle la carte enp4s0 en passthrough pour la réinstaller en mode pont/bridge (mode virtio) sur la VM de test. Et la surprise plus de trous de connexion ! Ça rejoindrais donc le fait que la carte gère mal la virtualisation ? Je repasse sur Alcasar, j'enlève la carte côté WAN en passthrough et la remonte en pont/bridge (mode e1000 comme préconisé sur la doc Installation Alcasar), je laisse la carte LAN en passthrough. Plus de trous connexion !! Et test de débit bouygues : curl -4 -o /dev/null https://bouygues.testdebit.info/10G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 9536M 100 9536M 0 0 42.1M 0 0:03:46 0:03:46 --:--:-- 41.2M Speedtest by Ookla [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Server Selection - Failed to find a working test server. (NoServers) Speedtest ne passe pas pour autant... Es-ce que je repasse en bridge la carte LAN aussi ? |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-09 16:33 | [forum:493203] |
|
Je ne peux pas faire le test a distance. Je ne suis pas sûr de pouvoir faire marcher la carte 2,5GB de la carte mère sous linux. (Il me semble que j'avais rapidement essayé et que ça ne fonctionnait pas). Si je change de carte que me conseilles-tu? Intel PRO/1000 PT Dual Port Server Adapter Adaptateur réseau PCI Express x4 Ethernet, Fast Ethernet, Gigabit Ethernet 10Base-T, 100Base-TX, 1000Base-T 2 ports https://www.amazon.fr/dp/B000BMZHX2/ref=cm_sw_r_apan_i_J2NBTWMRSJ44AH5XXTAX Par exemple ? Ou un autre lien ? Merci |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : nOx nOx on 2022-04-09 15:42 | [forum:493201] |
|
Ce n'est pas tant le débit qui est important, c'est le fait que ce ne soit pas stable et surtout que le VM n'ai pas le même débit que l’hôte. Il est très probable que ce qui cause cette instabilité soi la même chose qui fait planter le speedtest et qui fait qu'alcasar a des sautes d'humeur. POur moi il y a un prooblème avec cette carte réseau. Je vois que sur ta debian tu as 2 cartes Realtek. (Probablement le chipset et une carte additionnelle) RTL8125 2.5GbE et RTL8111/8168/8411. Peux tu faire un test avec un VM utilisant la carte RTL8125 au lieu du RTL8111. Si ton speedtest est équivalent a celui de la debian, alors tu pourras déduire que c'est la carte RLT8111 qui merdouille Au passage, j'ai personnellement laissé tombé les cartes Realtek sur mes serveur' il y a toujours des surprises. (Je ne prends plus que des intel) |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-09 12:22 | [forum:493200] |
|
Sur Debian (hôte KVM) cat /proc/version Linux version 5.10.0-9-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.70-1 (2021-09-30) Oui je vois. Mais même si le débit s’effondre, qu'es-ce qui explique le fait que l'authentification ne semble pas tenir et cette page E2Guardian ?? Pour les cartes réseaux je n'en ai pas d'autres.. Elles sont neuves. J'avais déjà utilisé ces cartes (en mode pont) sur d'autres install sans problèmes particulier. Le fait que le débit soit inférieur ne me gène pas énormément vu que je souhaitez même le brider. Après c'est sûr que si mon soucis vient de là c'est autre chose... J'aimerai comprendre pourquoi Alcasar ne fait pas le speedtest. Pour bien vérifier que le débit s’effondre aussi sur Alcasar (hôte). Car avec le test Bouygues c'est souvent équivalent. Car sur Alcasar, je suis donc sur une carte en pci passthrough mais sur la VM de test je suis sur des cartes bridge (avec VLAN géré par debian). Je refais de nouveau test : (bouygues pour pouvoir comparer) : Sur Debian : curl -4 -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 953M 0 0 41.8M 0 0:00:22 0:00:22 --:--:-- 40.5M curl -4 -o /dev/null --http1.1 -F "filecontent=@/tmp/temp.iso" https://bouygues.testdebit.info % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 105k 100 953M 3733 32.8M 0:00:29 0:00:29 --:--:-- 29.9M Sur Alcasar (hôte) : curl -4 -o /tmp/temp.iso http://bouygues.testdebit.info/1G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 953M 0 0 46.3M 0 0:00:20 0:00:20 --:--:-- 46.4M curl -4 -o /dev/null --http1.1 -F "filecontent=@/tmp/temp.iso" https://bouygues.testdebit.info % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 105k 100 953M 2410 21.2M 0:00:44 0:00:44 --:--:-- 23.8M Après mes tests de débit ne sont jamais pareil. Deux tests à la suite ne me sorte jamais le même débit (c'est aussi le cas lorsque je suis au cul de mon routeur/pare-feu, seul avec tout le réseau LAN de débrancher) Par contre, il me semble qu'il y a des "creux" pendant certains transfert depuis Alcasar (et je n'ai pas l'impression d'avoir ça sur l’hôte KVM). De nouveaux tests, les uns derrière les autres : (observer les Speed Average ; je supprime le fichier .iso entre chaque test) Sur Debian : curl -4 -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 953M 0 0 41.8M 0 0:00:22 0:00:22 --:--:-- 40.5M curl -4 -o /dev/null --http1.1 -F "filecontent=@/tmp/temp.iso" https://bouygues.testdebit.info % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 105k 100 953M 3733 32.8M 0:00:29 0:00:29 --:--:-- 29.9M curl -4 -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 953M 0 0 30.7M 0 0:00:31 0:00:31 --:--:-- 30.9M curl -4 -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 953M 0 0 47.2M 0 0:00:20 0:00:20 --:--:-- 47.8M curl -4 -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 953M 0 0 47.1M 0 0:00:20 0:00:20 --:--:-- 47.5M curl -4 -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 953M 0 0 41.8M 0 0:00:22 0:00:22 --:--:-- 38.9M Sur Alcasar : curl -4 -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 953M 0 0 44.8M 0 0:00:21 0:00:21 --:--:-- 47.4M curl -4 -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 953M 0 0 19.7M 0 0:00:48 0:00:48 --:--:-- 17.7M #Sur le test précédent, a certains moment cela descend en dessous 1M puis ça remonte à des valeurs normales curl -4 -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 953M 0 0 46.9M 0 0:00:20 0:00:20 --:--:-- 47.6M # Je test avec un transfert plus long : curl -4 -o /tmp/temp.iso https://bouygues.testdebit.info/10G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 50 9536M 50 4811M 0 0 25.3M 0 0:06:16 0:03:10 0:03:06 21.8M curl: (23) Failed writing body (6483 != 16375) #A planté car il n'y a plus eu de place sur /tmp Sur Debian : curl -4 -o /tmp/temp.iso https://bouygues.testdebit.info/10G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 9536M 100 9536M 0 0 46.6M 0 0:03:24 0:03:24 --:--:-- 47.6M Es-ce que je peux tenter une installation des pilotes realtek sur Alcasar ? Si oui comment ? Quel paquet utiliser ? Merci |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : nOx nOx on 2022-04-09 11:12 | [forum:493199] |
|
Ton download s'effondre quand tu est sur une VM. Debian Latency: 15.26 ms (0.03 ms jitter) Download: 590.14 Mbps (data used: 652.6 MB ) Upload: 853.65 Mbps (data used: 1.2 GB ) Acasar Problèmes VM Hote Latency: 15.89 ms (0.04 ms jitter) Download: 184.24 Mbps (data used: 168.6 MB ) Upload: 722.27 Mbps (data used: 755.0 MB ) Alcasar Bypass Porblème Pour moi, la 1ere étape ici est de régler ce problème. Les speedtests de l'hote et des VM doivent être presque identiques. Tu devrais perdre 0,5ms de ping, et rien d'autre. Les piste auxquelles je pense : - Des cartes réseau qui ne supportent pas la virtualisation ou qui sont mal supportées - Un problème de version de kernel (C'est quelle version que tu as sur ta débian) ou de pilote. (Voir celui du fabriquant) Connaissant bien debian, je pencherai plus pour un soucis avec la carte réseau. Si tu en as une autre sous la main, ce serait pas mal de tester. |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-09 10:44 | [forum:493198] |
|
Seul, je n'avais jusqu'à présent pas eu le problème. Là je viens de refaire le test (c'est moins régulier) mais j'ai eu une page E2Guardian à nouveau (wifi allumé, je ne peut le déconnecter à distance, avec aucun client connecté par contre). Sur la Debian : lspci : 00:00.0 Host bridge: Intel Corporation Comet Lake-S 6c Host Bridge/DRAM Controller (rev 03) 00:02.0 VGA compatible controller: Intel Corporation CometLake-S GT2 [UHD Graphics 630] (rev 03) 00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model 00:12.0 Signal processing controller: Intel Corporation Comet Lake PCH Thermal Controller 00:14.0 USB controller: Intel Corporation Comet Lake USB 3.1 xHCI Host Controller 00:14.2 RAM memory: Intel Corporation Comet Lake PCH Shared SRAM 00:16.0 Communication controller: Intel Corporation Comet Lake HECI Controller 00:17.0 SATA controller: Intel Corporation Device 06d2 00:1c.0 PCI bridge: Intel Corporation Device 06b8 (rev f0) 00:1c.4 PCI bridge: Intel Corporation Device 06bc (rev f0) 00:1c.5 PCI bridge: Intel Corporation Device 06bd (rev f0) 00:1c.6 PCI bridge: Intel Corporation Device 06be (rev f0) 00:1c.7 PCI bridge: Intel Corporation Device 06bf (rev f0) 00:1d.0 PCI bridge: Intel Corporation Comet Lake PCI Express Root Port #9 (rev f0) 00:1f.0 ISA bridge: Intel Corporation Device 0685 00:1f.3 Audio device: Intel Corporation Comet Lake PCH cAVS 00:1f.4 SMBus: Intel Corporation Comet Lake PCH SMBus Controller 00:1f.5 Serial bus controller [0c80]: Intel Corporation Comet Lake PCH SPI Controller 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 04) 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) 06:00.0 Non-Volatile memory controller: Sandisk Corp WD Black SN750 / PC SN730 NVMe SSD ip addr : 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether d8:bb:c1:46:d3:71 brd ff:ff:ff:ff:ff:ff 3: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000 link/ether 10:27:f5:c7:6e:11 brd ff:ff:ff:ff:ff:ff 6: lxcbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff inet 10.0.3.1/24 brd 10.0.3.255 scope global lxcbr0 valid_lft forever preferred_lft forever 7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether ae:bb:12:c6:e0:3d brd ff:ff:ff:ff:ff:ff inet6 fe80::acbb:12ff:fec6:e03d/64 scope link valid_lft forever preferred_lft forever 8: br0.15@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether ae:bb:12:c6:e0:3d brd ff:ff:ff:ff:ff:ff inet 192.168.123.40/24 brd 192.168.123.255 scope global br0.15 valid_lft forever preferred_lft forever inet6 fe80::acbb:12ff:fec6:e03d/64 scope link valid_lft forever preferred_lft forever 9: br0.2@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether ae:bb:12:c6:e0:3d brd ff:ff:ff:ff:ff:ff inet6 fe80::acbb:12ff:fec6:e03d/64 scope link valid_lft forever preferred_lft forever 10: br0.200@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether ae:bb:12:c6:e0:3d brd ff:ff:ff:ff:ff:ff inet6 fe80::acbb:12ff:fec6:e03d/64 scope link valid_lft forever preferred_lft forever 11: virbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 52:54:00:18:c0:15 brd ff:ff:ff:ff:ff:ff inet 172.16.68.1/24 brd 172.16.68.255 scope global virbr1 valid_lft forever preferred_lft forever 12: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UNKNOWN group default qlen 1000 link/ether fe:54:00:c8:c3:9d brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fec8:c39d/64 scope link valid_lft forever preferred_lft forever 13: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr1 state UNKNOWN group default qlen 1000 link/ether fe:54:00:37:ce:4b brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fe37:ce4b/64 scope link valid_lft forever preferred_lft forever 14: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UNKNOWN group default qlen 1000 link/ether fe:54:00:3c:c5:12 brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fe3c:c512/64 scope link valid_lft forever preferred_lft forever 15: vnet3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UNKNOWN group default qlen 1000 link/ether fe:54:00:e8:3c:19 brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fee8:3c19/64 scope link valid_lft forever preferred_lft forever 16: vnet4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr1 state UNKNOWN group default qlen 1000 link/ether fe:54:00:c7:ad:90 brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fec7:ad90/64 scope link valid_lft forever preferred_lft forever 17: vnet5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UNKNOWN group default qlen 1000 link/ether fe:54:00:26:d0:28 brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fe26:d028/64 scope link valid_lft forever preferred_lft forever 18: vnet6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr1 state UNKNOWN group default qlen 1000 link/ether fe:54:00:2c:53:7f brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fe2c:537f/64 scope link valid_lft forever preferred_lft forever 20: vnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UNKNOWN group default qlen 1000 link/ether fe:54:00:a4:1a:0a brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fea4:1a0a/64 scope link valid_lft forever preferred_lft forever 21: vnet9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr1 state UNKNOWN group default qlen 1000 link/ether fe:54:00:c1:39:7d brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fec1:397d/64 scope link valid_lft forever preferred_lft forever 26: vnet10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master virbr1 state UNKNOWN group default qlen 1000 link/ether fe:54:00:f2:d4:8b brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fef2:d48b/64 scope link valid_lft forever preferred_lft forever 27: macvtap0@br0.200: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 500 link/ether 52:54:00:b9:21:38 brd ff:ff:ff:ff:ff:ff inet6 fe80::5054:ff:feb9:2138/64 scope link valid_lft forever preferred_lft forever (Les interfaces br sont sur la carte enp3s0 (pour les autres VM et l'hôte) ; alcasar utilise les cartes enp4s0 et enp5s0) Speedtest by Ookla Server: Netprotect - Paris (id = 37599) ISP: UNYC SAS Latency: 15.26 ms (0.03 ms jitter) Download: 590.14 Mbps (data used: 652.6 MB ) Upload: 853.65 Mbps (data used: 1.2 GB ) Packet Loss: Not available. Result URL: https://www.speedtest.net/result/c/efa3b3fc-fb3d-4423-bcd7-640c47ef22a5 Speedtest bouygues : curl -4 -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 953M 0 0 47.2M 0 0:00:20 0:00:20 --:--:-- 47.6M curl -4 -o /dev/null --http1.1 -F "filecontent=@/tmp/temp.iso" https://bouygues.testdebit.info % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 105k 100 953M 4646 40.8M 0:00:23 0:00:23 --:--:-- 40.2M Alcasar : lspci : 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 VGA compatible controller: Red Hat, Inc. QXL paravirtual graphic card (rev 05) 00:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) 00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) 00:05.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) 00:05.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) 00:05.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) 00:05.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) 00:06.0 Unclassified device [00ff]: Red Hat, Inc. Virtio memory balloon 00:07.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) ip addr : 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: ens7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:f2:d4:8b brd ff:ff:ff:ff:ff:ff 3: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 10:27:f5:df:c8:77 brd ff:ff:ff:ff:ff:ff inet 192.168.123.49/24 brd 192.168.123.255 scope global ens3 valid_lft forever preferred_lft forever 4: ens4: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 60:32:b1:d8:c9:7d brd ff:ff:ff:ff:ff:ff 5: tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN group default qlen 100 link/none inet 192.168.182.1/24 scope global tun0 valid_lft forever preferred_lft forever (interface ens3 : WAN Alcasar ; interface ens4 : lan Alcasar) Speedtest by Ookla [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Error: [0] Timeout occurred in connect. [error] Server Selection - Failed to find a working test server. (NoServers) Alors que : ping speedtest.net PING speedtest.net (151.101.2.219) 56(84) bytes of data. 64 bytes from 151.101.2.219 (151.101.2.219): icmp_seq=1 ttl=60 time=15.6 ms 64 bytes from 151.101.2.219 (151.101.2.219): icmp_seq=2 ttl=60 time=15.4 ms 64 bytes from 151.101.2.219 (151.101.2.219): icmp_seq=3 ttl=60 time=15.3 ms 64 bytes from 151.101.2.219 (151.101.2.219): icmp_seq=4 ttl=60 time=15.5 ms 64 bytes from 151.101.2.219 (151.101.2.219): icmp_seq=5 ttl=60 time=15.6 ms ^C --- speedtest.net ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 10ms rtt min/avg/max/mdev = 15.320/15.481/15.563/0.146 ms Speedtest bouygues : curl -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 953M 0 0 47.2M 0 0:00:20 0:00:20 --:--:-- 47.7M curl -4 -o /dev/null --http1.1 -F "filecontent=@/tmp/temp.iso" https://bouygues.testdebit.info % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 105k 100 953M 4550 40.0M 0:00:23 0:00:23 --:--:-- 39.3M Depuis VM de test (relié au réseau sans passer par Alcasar) : ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:b9:21:38 brd ff:ff:ff:ff:ff:ff altname enp2s1 inet 192.168.123.50/24 brd 192.168.123.255 scope global dynamic ens1 valid_lft 315359946sec preferred_lft 315359946sec inet6 fe80::5054:ff:feb9:2138/64 scope link valid_lft forever preferred_lft forever Speedtest by Ookla Server: Netprotect - Paris (id = 37599) ISP: UNYC SAS Latency: 15.89 ms (0.04 ms jitter) Download: 184.24 Mbps (data used: 168.6 MB ) Upload: 722.27 Mbps (data used: 755.0 MB ) Packet Loss: Not available. Result URL: https://www.speedtest.net/result/c/02d54266-6be2-4dcf-bcb7-58f324b32eeb Speedtest Bouygues : curl -4 -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 953M 0 0 26.7M 0 0:00:35 0:00:35 --:--:-- 32.5M curl -4 -o /dev/null --http1.1 -F "filecontent=@/tmp/temp.iso" https://bouygues.testdebit.info % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 953M 100 105k 100 953M 3192 28.0M 0:00:33 0:00:33 --:--:-- 27.3M Depuis VM de test connecté à Alcasar en mode Bypass : ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:b9:21:38 brd ff:ff:ff:ff:ff:ff altname enp2s1 inet 192.168.182.72/24 brd 192.168.182.255 scope global dynamic ens1 valid_lft 21593sec preferred_lft 21593sec inet6 fe80::5054:ff:feb9:2138/64 scope link valid_lft forever preferred_lft forever Speedtest by Ookla Server: Netprotect - Paris (id = 37599) ISP: UNYC SAS Latency: 15.51 ms (0.06 ms jitter) Download: 102.43 Mbps (data used: 167.1 MB ) Upload: 688.92 Mbps (data used: 894.7 MB ) Packet Loss: Not available. Result URL: https://www.speedtest.net/result/c/a7f8207e-90e7-4da8-82d6-7413864c7a21 Depuis VM de test connecté à Alcasar (seul user connecté, filtrages activés, il m'a fallu reboot le serveur après un alcasar-bypass.sh --off) ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:b9:21:38 brd ff:ff:ff:ff:ff:ff altname enp2s1 inet 192.168.182.72/24 brd 192.168.182.255 scope global dynamic ens1 valid_lft 21593sec preferred_lft 21593sec inet6 fe80::5054:ff:feb9:2138/64 scope link valid_lft forever preferred_lft forever Le speedtest ne se lance pas non plus... Speedtest by Ookla [error] Error: [111] Connection refused [error] Error: [101] Network unreachable [error] Error: [111] Connection refused [error] Error: [111] Connection refused [error] Error: [101] Network unreachable [error] Error: [111] Connection refused [error] Error: [111] Connection refused [error] Error: [111] Connection refused [error] Error: [111] Connection refused [error] Error: [111] Connection refused [error] Server Selection - Failed to find a working test server. (NoServers) Fast.com : 99 Mbps down ; 81 Mbps up (j'ai eu parfois 300 Mbps down et 200 Mbps up lors de précédent test) |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : nOx nOx on 2022-04-09 08:55 | [forum:493197] |
|
Est ce que si tu n'es q'un filaire, c'est à dire avec le Wifi totalement éteint tu as le même problème. Box <RJ45> (AlcasarWAN-AlcasarLAN) <RJ45> switch <RJ45> PC1...PCn 1- Sur ta debian : lspci ip addr et faire un speedtest https://www.speedtest.net/fr/apps/cli 2- Sur alcasar lspci ip addr Speedtest 3- sur PC connecté sur ton lan en RJ45 ip addr Speedtest 4- sur PC connecté sur ton lan en RJ45 alcasar en BYPASS (alcasar-bypass.sh --on) ip addr Speedtest |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-08 18:46 | [forum:493196] |
|
Les deux. Après mon message de ce matin, une personne m'a envoyé ce message : - Au niveau du wi-fi je passe sans arrêt de "Limité, ouvert" à "Connecté, ouvert" avec une notification "Action requise pour cfppa" - Une fois connecté, j'arrive à faire 1 seule recherche avec Google Chrome, le deuxième clic coince et me fait apparaître systématiquement "Action requise pour cfppa" et une erreur dans le navigateur - Quel que soit mon navigateur Edge, Firefox ou Chrome, j'ai un onglet de E2Guardian avec oops! There seem to be an issue... The site is not responding Your detail are below User: Group: blacklisted users IP: 192.168.182.212 - Lorsque je suis en mode limité ouvert, les comportement des navigateurs diffèrent * google chrome = j'arrive à faire une recherche dans google puis au clic suivant dans les recherches j'arrive sur E2Guardian * Firefox se lance mais m'affiche le bandeau "Ce réseau nécessite que vous vous connectiez..." et le bouton "Afficher la page de connexion réseau" qui si je clique dessus me renvoie sur le oops de E2Guardian * Edge = direct en page E2guardian (cfppa est le nom du réseau wifi, ouvert car il n'a pas de mot de passe). Lui et les personnes avec lui étaient sous une borne wifi effectivement. A peut près au même moment, je faisais moi mes tests a distance sur cette VM de test (donc relié en filaire). Avec des comportements similaires à ce que lui m'a décrit . Cette page qu'il parle est équivalente à la page que j'ai mis en pièce jointe sur mon précédent message. Merci |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : nOx nOx on 2022-04-08 18:30 | [forum:493195] |
|
Question : Ce sont des clients filaires ou wifi ? |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-08 10:11 | [forum:493191]
CaptureEcran.png (2) downloads
|
|
Je poursuis mes tests. Ce matin j'ai une dizaine de personne connecté et voilà ce que j'ai : (je suis sur une VM sur le même KVM, je passe juste par un seul switch (que je maitrise) entre le serveur Alcasar et ma VM de test). Pas de déconnexion du lien, je ping le serveur alcasar sans coupure en moins d'1ms. Les pages s'ouvre de manière intermittente. Cette fois, un test dig (par exemple : dig meteofrance.com @192.168.182.1) renvoi bien les infos (au moment où les pages ne charge plus). Par contre, je remarque à ce moment là que le navigateur me redemande d'aller sur la page de connexion au réseau. Si je clique, j'ai soit la page de status qui s'affiche (déjà authentifié) soit une page de blocage E2Guardian me disant que le site ne répond pas (detectportal.firefox...). Voir capture écran. Dans les logs, au même moment, je retrouve ça : /var/log/unbound/unbound-blacklist.log : [1649403311] unbound[1818:0] info: alcasar.mondomaine.fr. transparent 192.168.182.72@38237 alcasar.mondomaine.fr. AAAA IN [1649403311] unbound[1818:0] info: alcasar.mondomaine.fr. transparent 192.168.182.72@57450 alcasar.mondomaine.fr. A IN [1649403311] unbound[1818:0] info: alcasar.mondomaine.fr. transparent 192.168.182.72@57450 alcasar.mondomaine.fr. AAAA IN [1649403311] unbound[1818:0] info: alcasar.mondomaine.fr. transparent 192.168.182.72@51790 alcasar.mondomaine.fr. A IN [1649403311] unbound[1818:0] info: alcasar.mondomaine.fr. transparent 192.168.182.72@51790 alcasar.mondomaine.fr. AAAA IN [1649403311] unbound[1818:0] info: alcasar.mondomaine.fr. transparent 192.168.182.72@46878 alcasar.mondomaine.fr. A IN [1649403311] unbound[1818:0] info: alcasar.mondomaine.fr. transparent 192.168.182.72@46878 alcasar.mondomaine.fr. AAAA IN [1649403311] unbound[1818:0] info: alcasar.mondomaine.fr. transparent 192.168.182.72@51050 alcasar.mondomaine.fr. A IN [1649403311] unbound[1818:0] info: alcasar.mondomaine.fr. transparent 192.168.182.72@51050 alcasar.mondomaine.fr. AAAA IN [1649403311] unbound[1818:0] info: alcasar.mondomaine.fr. transparent 192.168.182.72@60632 alcasar.mondomaine.fr. A IN [1649403311] unbound[1818:0] info: alcasar.mondomaine.fr. transparent 192.168.182.72@60632 alcasar.mondomaine.fr. AAAA IN De nombreuses fois. L'ip .72 correspondant à ma VM de test. Pour vérifier qu'il n'y a pas de problème avec LDAP, j'utilise pour ce test un compte utilisateur créer dans Alcasar. |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-07 19:12 | [forum:493172] |
|
Non je ne trouve pas ça simpliste ! Je passe actuellement par des liaisons que je ne maîtrise pas ! Notamment entre les bâtiments. Néanmoins j'ai le soucis à proximité du serveur Alcasar aussi, sur une partie qui ne passe que sur de la partie maîtrisé (entre Alcasar et l'équipement de consultation) La sensation est globale sur le réseau, depuis les dernières modifications, je n'ai plus l'impression d'avoir de souci sur un équipement en particulier, puis un autre. C'est vraiment tout fonctionne ou d'un coup l'ouverture de page web ne fonctionne plus. Dans ce même temps, j'ai pu ce matin me déconnecter (via la page de status) et me re-loguer derrière. Je pensais pour ma part au DNS, le site https://1.1.1.1 s'ouvrant sans problème lors des tests. J'ai pu hier faire des dig (sur un poste de consultation) lorsqu'il y avait le souci, la requête revenait sans IP google.fr IN A [rien] Au même moment ping et dig fonctionnait sur le serveur Alcasar directement. Je n'ai jamais précisé, mais le réseau est essentiellement sur du wifi (avec des smartphone et pc portable). A midi, voyant que le problème continuait, j'ai réinstaller complètement Alcasar. Au vu du nombre connecté cet après midi (inférieur a 10), je suis presque sûr que le problème est toujours là. Il y a une bonne cinquantaine voire centaine de "client" qui aimerait ce connecter. Néanmoins, certains doivent ce décourager quand ils voient que cela ne fonctionne pas.. Sur la même infrastructure, j'ai deux réseaux qui passe sans problèmes particuliers (il ne sont pas sous Alcasar) et ils sont utilisés par de nombreux utilisateurs. Merci encore pour tout ! |
|
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : Nicolas REYNAUD on 2022-04-07 18:49 | [forum:493171] |
| *Semble redevenir ok après l'exécution de watchdog. | |
| RE: Lenteur générale réseau Alcasar [ Répondre ] Par : nOx nOx on 2022-04-07 18:49 | [forum:493170] |
|
Coté Hard, ca semble OK. Tu vas trouver ca un peu simpliste ce que je vais te dire, mais on a galéré 2 ans a cause ca sur un grosse infra avant de trouver : As tu testé avec d'autres cables RJ45 par des câblé de qualité. Pour l'histoire, on avait des comportement étranges, lenteurs, instabilité du wifi, problème d’authentification, etc... On avait pourtant testé tous les cables. Et bien on acheté des cables pro. Ca a tout réglé. |
|
Messages plus anciens 
|
