Pages: 1 2 3 [4] 5 6 7 8 9 ... 23   En bas

Auteur Sujet: [Demi-Résolu] Icotera - Déconnexion / Micro-coupures - Problème LAN/WAN  (Lu 30918 fois)

0 Membres et 1 Invité sur ce sujet

Steph

  • Abonné K-Net
  • *
  • Messages: 7 676
  • La Balme de Sillingy 74
    • Uptime K-net
Perte de la résolution des DNS (mac ocs)
« Réponse #36 le: 08 avril 2022 à 16:56:42 »
Citation de: Superpicsou le 08 avril 2022 à 16:03:45
L'ONT sur le WAN
Puis après ça passe de la box a la baie de la maison pour les connexions filaire.
Et le wifi bas, wifi.
Ya en plus une box ADSL mais rien de branché dessus à part le téléphone (comment ça ya un téléphone sur le kbox?)
Bin c'est tout bon.
Bizarre et anormal de voir d'autres clients K-net (avec du Netgear, Fortigate...) et la passerelle (.254) sur ton lan.

Ça aurait passionné les anciens employés de K-net qui t'auraient résolu le soucis en trois clics avec le forum CAPS!
IP archivée

Superpicsou

  • Abonné Free fibre
  • *
  • Messages: 302
  • Feuguerolles-Bully (14)
    • Cloud Illustrations
Perte de la résolution des DNS (mac ocs)
« Réponse #37 le: 08 avril 2022 à 16:59:52 »
Est-ce que ça aurait un lien avec le post de bolemo sur l'équipement qui spam sur le réseaux ?

https://lafibre.info/k-net-incident/ca-recommence-spam-eleve-de-trames-ipv6-dans-le-gpon-k-net-covage-14-et-91/msg942119/#new
IP archivée

pju91

  • Abonné Free fibre
  • *
  • Messages: 861
  • 91
Perte de la résolution des DNS (mac ocs)
« Réponse #38 le: 08 avril 2022 à 17:21:27 »
Citation de: Superpicsou le 08 avril 2022 à 16:59:52
Est-ce que ça aurait un lien avec le post de bolemo sur l'équipement qui spam sur le réseaux ?
Sauf erreur, bolemo n'observe rien sur son LAN (mais je crois qu'il n'utilise pas de K-Box)
Est-ce que la K-Box ne résiste pas au trafic WAN irrégulier et se met à fuire ? Je n'en sais rien, mais les paquets qu'on voit côté LAN ne sont pas ceux du "bug" qui préoccupe bolemo.
IP archivée

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 623
  • Grandcamp Maisy (14)
Perte de la résolution des DNS (mac ocs)
« Réponse #39 le: 08 avril 2022 à 17:24:40 »
Citation de: Superpicsou le 08 avril 2022 à 16:59:52
Est-ce que ça aurait un lien avec le post de bolemo sur l'équipement qui spam sur le réseaux ?

https://lafibre.info/k-net-incident/ca-recommence-spam-eleve-de-trames-ipv6-dans-le-gpon-k-net-covage-14-et-91/msg942119/#new

Clairement ça ne t'aide pas…

1) Tu es dans le 14 (comme moi), et le GPON du 14 est floodé de requêtes DHCPv6 (environ 4 000 per seconde !)

2) Il y a un perméabilité WAN/LAN anormale sur ton Icotera sur l'ethernet et le wifi 2,4GHz, du coup, le flood passe dans ton LAN…

Tu peux essayer ceci (pas en 5GHz donc) : sudo tcpdump -v udp port 547
Prépare toi à faire un ^C (Contrôle-C) pour interrompre, car tu risque de voir ta fenêtre de terminal se remplir très très vite…


Tout cela étant dit, je soupçonne que ces deux problèmes soient liés… Je pense que les configs de certaines Icotera deviennent complètement corrompues… Un Icotera sur notre GPON est responsable de ce flood (elle a pour MAC WAN 00:1e:80:74:7b:98), probablement suite à une telle corruption.
La tienne semble aussi corrompue… Les règles iptables pour les réseaux LAN ethernet et wifi 2,4 GHz ne sont absolument pas bonnes, ou un réglage forwarding est activé là où il ne devrait pas…
Par contre, le réseau LAN wifi 5 GHz lui est normal.
IP archivée

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 623
  • Grandcamp Maisy (14)
Perte de la résolution des DNS (mac ocs)
« Réponse #40 le: 08 avril 2022 à 17:31:37 »
Citation de: pju91 le 08 avril 2022 à 17:21:27
Sauf erreur, bolemo n'observe rien sur son LAN (mais je crois qu'il n'utilise pas de K-Box)
Est-ce que la K-Box ne résiste pas au trafic WAN irrégulier et se met à fuire ? Je n'en sais rien, mais les paquets qu'on voit côté LAN ne sont pas ceux du "bug" qui préoccupe bolemo.

J'ai un routeur perso, et un pare-feu bien solide. J'ai ultra protégé mon LAN avec entre autres des règles ebtables, iptables et Cie que j'ai établies à la main… Donc tous les paquets qui ne sont pas destinés à mon LAN sont bloqués à la porte de mon routeur.
Mais je peux écouter à la porte de mon routeur sur le WAN, et en effet, il y a plein de paquets APIPA et autres… J'en avais parlé à l'époque sur le forum Caps.

En principe, les réglages de base de tout routeur ou toute box doit bloquer ces paquets, mais ici, pour Superpicsou, il est évident que l'Icotera ne fait pas son boulot.
Comme il est dans le 14, et comme les paquets passent à travers son Icotera comme le vent à travers une passoire, je suis assez sûr que le flood DHCPv6 passe au travers. La requête  tcpdump -ne arp  ne les montre pas, mais tcpdump -v udp port 547 permet de les voir…

D'ailleurs, je vois bien les mêmes choses que lui côté WAN (depuis mon routeur) :
Code: [Sélectionner]
root@HERMES:~$  tcpdump -i ethwan -ne arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ethwan, link-type EN10MB (Ethernet), capture size 262144 bytes
17:30:56.543745 00:1e:80:93:0b:58 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:30:56.977110 00:1e:80:93:04:b0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:30:57.352805 e0:10:7f:2c:73:d0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.238.5.252 tell 0.0.0.0, length 46
17:30:57.543839 00:1e:80:93:0b:58 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:30:57.977047 00:1e:80:93:04:b0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:30:58.543776 00:1e:80:93:0b:58 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:30:58.899946 e8:fc:af:7b:4f:25 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.238.4.147 tell 185.238.6.208, length 46
17:30:58.977141 00:1e:80:93:04:b0 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
17:31:00.205288 00:1e:80:74:a3:b8 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 185.238.7.116 tell 185.238.7.116, length 46
17:31:00.486107 04:42:1a:2e:9d:f5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 2.59.238.55 tell 2.59.238.55, length 46
17:31:01.548931 00:1e:80:93:0b:58 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 169.254.1.1 tell 169.254.1.3, length 46
IP archivée

Superpicsou

  • Abonné Free fibre
  • *
  • Messages: 302
  • Feuguerolles-Bully (14)
    • Cloud Illustrations
Perte de la résolution des DNS (mac ocs)
« Réponse #41 le: 08 avril 2022 à 17:33:42 »
3000 lignes en une seconde mdr du coup voici que les 10 premières.
Ce qui est "drole" avec ce soucis de "fuite" réseau, c'est que le macbook apprécie pas du tout ces "spams", dit merde et se deconnecte. Alors que pour windows, pas soucis, on s'en fou et on garde la connexion.

Code: [Sélectionner]

╰─$ sudo tcpdump -v udp port 547
tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
17:29:28.042192 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.043363 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.048584 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.055460 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.056595 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.061803 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
^C
3660 packets captured
3740 packets received by filter
0 packets dropped by kernel
IP archivée

pju91

  • Abonné Free fibre
  • *
  • Messages: 861
  • 91
Perte de la résolution des DNS (mac ocs)
« Réponse #42 le: 08 avril 2022 à 17:40:16 »
Citation de: Superpicsou le 08 avril 2022 à 17:33:42
3000 lignes en une seconde mdr du coup voici que les 10 premières.
Ce qui est "drole" avec ce soucis de "fuite" réseau, c'est que le macbook apprécie pas du tout ces "spams", dit merde et se deconnecte. Alors que pour windows, pas soucis, on s'en fou et on garde la connexion.
quelques commentaires :
- bolemo n'a pas évidemment pas rêvé concernant ce trafic fou côté WAN, d'autres le voient.
- ça ne devrait pas traverser la box de superpicsou. Soit elle est "cassée", soit le câblage est différent de ce que tu indiques.
- petite suggestion : désactiver IPv6 sur le Mac, car à ma connaissance IPv6 n'a pas été rétabli sur le réseau K-Net et donc ça ne sert à rien sur les postes. Ca n'empêchera pas le trafic d'arriver sur le LAN, mais ça soulagera peut-être le Mac.
- je ne propose évidemment pas de mettre une règle de filtrage sur cette box qui fait n'importe quoi.
IP archivée

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 623
  • Grandcamp Maisy (14)
Perte de la résolution des DNS (mac ocs)
« Réponse #43 le: 08 avril 2022 à 17:40:38 »
Citation de: Superpicsou le 08 avril 2022 à 17:33:42
3000 lignes en une seconde mdr du coup voici que les 10 premières.
Ce qui est "drole" avec ce soucis de "fuite" réseau, c'est que le macbook apprécie pas du tout ces "spams", dit merde et se deconnecte. Alors que pour windows, pas soucis, on s'en fou et on garde la connexion.

Code: [Sélectionner]
Last login: Fri Apr  8 16:36:41 on ttys001

╰─$ sudo tcpdump -v udp port 547
tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
17:29:28.042192 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.043363 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.048584 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.055460 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.056595 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
17:29:28.061803 IP6 (hlim 64, next-header UDP (17) payload length: 126) fe80::21e:80ff:fe74:7b98.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=a35c40 (elapsed-time 47904) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list NTP-server AFTR-Name opt_67) (client-ID hwaddr type 1 001e80747b98) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/64 pltime:0 vltime:0)))
^C
3660 packets captured
3740 packets received by filter
0 packets dropped by kernel

CQFD…

Sinon, pour le coup, ça peut être un conflit ARP et/ou d'IP… Parce que ton LAN, il inclut toutes les machines présentent dans le GPON ! Et il y en a un paquet avec des adresses comme 192.168.1.1
J'avais fait un recensement il y a quelques années, avec un arpscan poussé (quand on le pouvait encore), et c'était ahurissant le nombre de machines qui sont dans le GPON et ne devraient pas y être… Des fuites LAN/WAN.
Donc pourquoi ton MacBook se déconnecte devient très difficile à diagnostiquer… Mais clairement, utilise le réseau 5GHz… Et je conseille fortement de faire pareil pour des autres appareils… Car pour l'instant, tout ce qui est sur ton LAN en ethernet et wifi 2,4 GHz est grand ouvert sur tout le GPON  :-\
IP archivée

pju91

  • Abonné Free fibre
  • *
  • Messages: 861
  • 91
Perte de la résolution des DNS (mac ocs)
« Réponse #44 le: 08 avril 2022 à 17:53:10 »
Citation de: bolemo le 08 avril 2022 à 17:40:38
Car pour l'instant, tout ce qui est sur ton LAN en ethernet et wifi 2,4 GHz est grand ouvert sur tout le GPON  :-\
Pour éviter que superpicsou fasse des cauchemars devant son réseau grand ouvert, précisons quand même que ce qu'on a vu sur les traces est du trafic broadcast ou multicast (IPv6), pas de l'unicast.
Ses machines ne sont a priori pas directement accessibles (faute de route vers 192.168.1.0/24 qui amènerait chez lui).
IP archivée

Superpicsou

  • Abonné Free fibre
  • *
  • Messages: 302
  • Feuguerolles-Bully (14)
    • Cloud Illustrations
Perte de la résolution des DNS (mac ocs)
« Réponse #45 le: 08 avril 2022 à 17:55:19 »
Bon bas en tout cas merci pour vos réponses et votre patience.
J'ai envoyé un mail recap à Knet pour qu'ils regardent ce qu'ils peuvent faire au niveau de ma box.
Je vais appliquer les rustines que vous avez proposé en attendant.


Merci
IP archivée

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 623
  • Grandcamp Maisy (14)
Perte de la résolution des DNS (mac ocs)
« Réponse #46 le: 08 avril 2022 à 18:01:17 »
Citation de: pju91 le 08 avril 2022 à 17:53:10
Pour éviter que superpicsou fasse des cauchemars devant son réseau grand ouvert, précisons quand même que ce qu'on a vu sur les traces est du trafic broadcast ou multicast (IPv6), pas de l'unicast.
Ses machines ne sont a priori pas directement accessibles (faute de route vers 192.168.1.0/24 qui amènerait chez lui).

Oui, seulement l'arp, le broadcast et le multicast passent (dans les deux sens), donc pas aussi grave que si tout l'unicast était visible, mais ça reste une grosse faille de sécurité…
Toutes les adresses MAC (et donc le type de matériel) du LAN sont visibles si elles utilisent arp… Les IPs, le type de logiciels (pour ceux qui font du boradcast/multicast)… Bref, pas mal d'info déjà.

En fait, on pourrait faire une app pour communiquer entre clients K-Net sur un même GPON via des paquets broadcast ou multicast  ;D
IP archivée

Superpicsou

  • Abonné Free fibre
  • *
  • Messages: 302
  • Feuguerolles-Bully (14)
    • Cloud Illustrations
Perte de la résolution des DNS (mac ocs)
« Réponse #47 le: 08 avril 2022 à 18:03:11 »
Un netsend comme sur windows98, le rêve.
IP archivée
Pages: 1 2 3 [4] 5 6 7 8 9 ... 23   En haut