Il y a deux jours, Microsoft a diffusé la mise à jour KB5039302 pour Windows 10 et 11. Contrairement aux mises à jour mensuelles (chaque deuxième mardi de chaque mois) dédiées à la sécurité, elle apportait plusieurs améliorations fonctionnelles pour Windows 11.
Le bouton permettant d’afficher rapidement le bureau est ainsi revenu par défaut. L’Explorateur de fichiers a gagné la capacité de créer des archives 7-Zip et TAR, le menu Partage reçoit une fonction Copier, le support de la norme Emoji passe à la version 15.1 (mouvements de tête, citron vert, phénix…) ainsi qu’un certain nombre de corrections de bugs.
Mais cette KB5039302 introduit un loup. Comme pointé par Neowin et confirmé par Microsoft dans la liste des problèmes connus pour les versions 22H2 et 23H2 de Windows 11, la nouvelle mise à jour peut entrainer des redémarrages en boucle chez certains utilisateurs.
« Ce problème est plus susceptible d'affecter les appareils utilisant des outils de machines virtuelles et des fonctions de virtualisation imbriquées, telles que CloudPC, DevBox, Azure Virtual Desktop. Nous enquêtons pour déterminer les conditions précises dans lesquelles ce problème peut se déclencher », indique Microsoft.
« Les utilisateurs de l'édition familiale de Windows sont moins susceptibles de rencontrer ce problème, car la virtualisation est moins répandue dans les environnements domestiques », ajoute l’entreprise. Elle a donc décidé de suspendre le déploiement de la mise à jour. Une nouvelle version sera proposée quand la cause du problème aura été déterminée.
Heureusement, cette mise à jour n’est pas déployée automatiquement, contrairement aux correctifs de sécurité. Pour l’obtenir, il faut avoir cliqué sur le bouton « Rechercher des mises à jour » dans Windows Update et activé le réglage « Recevez les dernières mises à jour dès qu’elles sont disponibles ».
Commentaires (27)
#1
(Je sais même plus comment aller dans le mode sans echec de Windows 11 tellement le boot a changé ^^' )
Historique des modifications :
Posté le 28/06/2024 à 10h51
Question bête mais si ta machine reboot en boucle. Tu fais quoi ? Mode sans echec et uninstall de l'update en question ?
(Je sais même si ya un mode dans echec dans Windows 11 tellement le boot a changé ^^' )
#1.1
#1.2
Et normalement, il y a un point de restauration créé avant chaque installation de mise à jour.
#1.3
Dans ce cas on sait pas si le reboot se fait une fois dans Windows ou avant le login.
Il faut encore espérer que le mode sans echec ne soit pas affecté par cette update
Historique des modifications :
Posté le 28/06/2024 à 11h32
Y'avait pas un truc dans Windows que quand le boot a fonctionné, c'est considéré comme une bonne config par Windows. Et si on choisis "revenir a une configuration fonctionnelle" en mode sans echec, il va juste revenir a une config problématique![:fou:](https://cdn2.nextinpact.com/smileys/fou.gif)
![:D](https://cdn2.nextinpact.com/smileys/icon_mrgreen.gif)
Il faut encore espérer que le mode sans echec ne soit pas affecté par cette update
#1.4
#1.5
Cela fait 1 an que j'ai une petit CG Nvidia GT1030. Ils se sont améliorés, je n'ai plus eu de BSOD après mise à jour du driver (2 fois), mais un affichage qui saute environ toute les 6 secondes pour une dizaine de secondes, avec les 2 maj de drivers installées depuis 1 an :( Mauvaise pioche?
#1.6
Et d'ordre général, quand ça concerne ma seule machine sous Windows qui n'est qu'une console Steam / FFXIV, je cherche pas à savoir plus. En dehors de ça, j'ai eu toute ma vie des Nvidia et ne m'en suis jamais plaint. Mon seul GPU ATI fut celui de la Gamecube !
#1.7
Ça m'était arrivé une fois, après une mise à jour Windows, de restaurer comme ça des ruches de registres (venant de feu le dossier RegBack), ce qui a fonctionné, puis par essais en machine virtuelle à partir d'une image disque du système défectueux, d'affiner jusqu'à trouver LA clé de registre que la mise à jour avait corrompu (supprimée alors qu'apparemment indispensable pour démarrer).
#2
Perso, j'utilise les outils de virtualisation pour pouvoir faire enfin un truc banal depuis des années sous linux: ajouter une carte réseau sur un VLAN tout en conservant la carte principale pour les paquets sans l'entête 802.1q
C'était une galère sans nom quand seuls deux fabricants de cartes réseaux (intel et realtek), permettaient de le faire via un des pilotes spéciaux et une configuration un peu compliquée.
Pour ceux qui se demande pourquoi faire une telle chose, cela permet de circonscrire le traffic SMB au réseau local Ethernet. Ce qui est dans un VLAN n'est pas routé par les box et n'est pas disponible sur le wifi.
Attention de ne pas utiliser le VLAN 100 cependant avec une freebox car c'est celui utilisé entre le serveur et le lecteur multimédia: un préfixe IPv6 global y est annoncé et il est partagé sur le Wifi et les ports Ethernet.
Historique des modifications :
Posté le 28/06/2024 à 11h34
On peut donc être concernés même si on n'utilise pas directement la virtualisation.
Perso, j'utilise les outils de virtualisation pour pouvoir faire enfin un truc banal depuis des années sous linux: ajouter une carte réseau sur un VLAN tout en conservant la carte principale pour les paquets sans l'entête 802.1q
C'était une galère sans nom quand seuls deux fabricants de cartes réseaux (intel et realtek), permettaient de le faire via un des pilotes spéciaux et une configuration un peu compliquée.
Pour ceux qui se demande pourquoi faire une telle chose, cela permet de circonscrire le traffic SMB au réseau local Ethernet. Ce qui est dans un VLAN n'est pas routé par les box et n'est pas disponible sur le wifi.
Attention de ne pas utiliser le VLAN 100 cependant avec une freebox car c'est celui utilisé entre le serveur et le lecteur multimédia: un préfixe IPv6 global y est annoncé et il est partagé sur le Wifi et les ports Ethernet.
#2.1
Côté Orange, le vlan 835 (reliquat d’une vieille configuration 8/35 de je-ne-sais-quoi) est utilisé pour l’accès à la fibre via l’ONT (mais je crois que c’est uniquement quand on se passe de la Livebox).
Édit : correction du numéro de vlan Orange, merci @renaud07
Historique des modifications :
Posté le 28/06/2024 à 11h48
Ni le vlan 400, d’ailleurs. Je ne sais pas pour quoi il est utilisé exactement mais la Freebox Révolution cherche en permanence une autre machine dessus.
Côté Orange, le vlan 836 (reliquat d’une vieille configuration 8/36 de je-ne-sais-quoi) est utilisé pour l’accès à la fibre via l’ONT (mais je crois que c’est uniquement quand on se passe de la Livebox).
#2.3
#2.2
#2.4
Les plus vieux paranos d'entres-nous (donc moi) utilisent leur propre routeur et font du bridge/double-NAT avec la box. Mais le VLAN est une solution moderne élégante.
#2.5
#2.6
#2.7
640K4 Bytes ought to be enough for anyone."#2.9
le SMB sur IPv6 fonctionne très bien et permet de couper définitivement l’infâme service de nom netbios qui est mécaniquement incompatible IPv6.
Côté serveur, mes machines virtuelles sont quasiment à 100% en IPv6: c'est un mandataire inversé nginx qui reçois les connexions en IPv4 et les retransmet par détection de flux au bon serveur en IPv6 avec le protocole proxy.
Le traffic reste chiffré jusqu'au serveurs finaux car l'aiguillage se fait sur le flux lors de la phase de connexion SSL avec le paquet HELO. Pas besoin de gérer les certificats sur l’hôte.
Il me reste encore une dernière chose à faire pour bouter l'IPv4 de ces machines: mettre en place un NAT64 et un DNS64. Mais tayga est chiant à configurer donc je n'ai pas encore résussi.
#2.10
Et d'être retourné en cours de réseau.
Historique des modifications :
Posté le 29/06/2024 à 10h33
J'ai l'imprimer de lire/entendre un collègue ! 😅
Et aussi d'être retourné en cours de réseau.
#2.11
IPv4, c'est le passé, et il est plus que temps de passer à la suite.
De mon côté, je m'active à lui creuser sa tombe et je fêterai dignement son enterrement.
Historique des modifications :
Posté le 29/06/2024 à 10h55
IPv4, c'est le passé, et il est plus que temps de passer à la suite.
De mon côté, je m'active à lui creuser sa tombe et je fêterai dignement son enterrement.
#2.12
J'imagine que tu parlais de SNI dans le ClientHello de TLS.
#2.13
Globalement, le message que j'essaye de faire passer est pour ceux qui n'ont pas ton degré de compétences. Je reformule donc:
Avec les modules de type flux de nginx, il est possible de router automatiquement les connexions https vers la bonne destination et le protocole proxy sans sacrifier la confidentialité des échanges.
Le mandataire inverse est capable de déterminer cela à partir du tout premier paquet envoyé par le client https car ce paquet est en clair.
Le protocole proxy permet de transmettre au serveur destinataire l'adresse ip du client et d'autres informations.
Du coup, les flux https IPv4 arrivent au mandataire qui les renvoie en IPv6 au serveurs IPv6 only par protocole proxy sur des adresses ULA. Les flux IPv6 arrivent directement aux serveurs.
Bref, il est possible et même très simple d'arrêter de faire du NAT44 comme des idiots pour des serveurs en conteneurs ou en machines virtuelles en migrants sur IPv6
#2.14
Mon degré de compétences comme tu dis s'arrête à TLS; niveau réseau je suis une bille (j'espère que mes profs d'école d'ingé TelCo ne me liront pas ici 😬).
Globalement je fais transporter mes paquets avec IPv6 (VPN, réseau local), mais j'ai encore beaucoup de mal à manier tout ça, parce que je ne trouve pas l'IPv6 super intuitif, les adresses sont terribles à parser pour le grep-with-my-poor-human-eyes…
Il faudrait que j'essaie de jouer avec tout ça et essayer de reproduire ton setup. Ça pourrait être un projet cool.
Sinon, pour ce qui est du routing niveau applicatif, nginx c'est super mais je trouve sa configuration un poil primaire.
J'utilise Envoy personnellement, c'est assez avancé, la configuration s'écrit dans un peu n'importe quoi qui peut se mapper en protobuf.
EDIT: t'as une RFC[1] pour des ClientHello chiffrés en TLS 1.3, c'est cool, et ta confidentialité s'en retrouve encore plus grandie. D'un point de vue on-path attack, il n'y aurait plus que le routing qui pourrait leaker des informations.
Manque plus que OpenSSL le supporte pour l'avoir de-facto dans nginx (BoringSSL le supporte déjà, Envoy utilise BoringSSL).
[1]: https://www.ietf.org/archive/id/draft-ietf-tls-esni-18.txt
Historique des modifications :
Posté le 30/06/2024 à 11h17
Merci pour ces détails! :)
Mon degré de compétences comme tu dis s'arrête à TLS; niveau réseau je suis une bille (j'espère que mes profs d'école d'ingé TelCo ne me liront pas ici 😬).
Globalement je fais transporter mes paquets avec IPv6 (VPN, réseau local), mais j'ai encore beaucoup de mal à manier tout ça, parce que je ne trouve pas l'IPv6 super intuitif, les adresses sont terribles à parser pour le grep-with-my-poor-human-eyes…
Il faudrait que j'essaie de jouer avec tout ça et essayer de reproduire ton setup. Ça pourrait être un projet cool.
Sinon, pour ce qui est du routing niveau applicatif, nginx c'est super mais je trouve sa configuration un poil primaire.
J'utilise Envoy personnellement, c'est assez avancé, la configuration s'écrit dans un peu n'importe quoi qui peut se mapper en protobuf.
#2.15
J'avais expérimenté de ne plus distribuer les préfixes des WAN vers le LAN et de n'utiliser que des adresses locales sur le LAN, et ensuite soit de faire du NTP (qui me paraissait plutôt élégant), soit de faire du NAT66 (qui l'est beaucoup moins).
Dans les deux cas cependant le routeur doit faire du suivi de connexion pour que chaque connexion ouverte continue de passer par le WAN par lequel elle est passée au moment de son ouverture. Je précise que chaque machine du LAN n'a pas de WAN assigné et que ça peut changer dynamiquement au choix du routeur en fonction de la charge. Bien sûr au moment d'un changement brusque, typiquement en cas de panne d'un WAN, on accepte que des connexions ouvertes soient cassées mais les suivantes sortantes ou entrantes doivent fonctionner.
Le LAN n'a donc plus d'adresse publique, ce qui peut peut-être gêner certains serveurs, mais peut-être pas. Y a-t-il un autre moyen de faire ou est-ce que c'est la bonne (le NTP je suppose) ?
Historique des modifications :
Posté le 01/07/2024 à 09h57
Vu que tu as l'air calé en IPv6, quelle technique tu préconiserais pour un LAN connecté à plusieurs accès Internet avec chacune son propre préfixe IPv6 ? Autant pour les clients que pour les serveurs hébergés sur le LAN et qui doivent être accessibles depuis tous les WAN ?
J'avais expérimenté de ne plus distribuer les préfixes des WAN vers le LAN et de n'utiliser que des adresses locales sur le LAN, et ensuite soit de faire du NTP (qui me paraissait plutôt élégant), soit de faire du NAT66 (qui l'est beaucoup moins).
Dans les deux cas cependant le routeur doit faire du suivi de connexion pour que chaque connexion ouverte continue de passer par le WAN par lequel elle est passée au moment de son ouverture. Je précise que chaque machine du LAN n'a pas de WAN assigné et que ça peut changer dynamiquement au choix du routeur en fonction de la charge. Bien sûr au moment du changement brusque, typiquement en cas de panne d'un WAN, on accepte que des connexions ouvertes soient cassées mais les suivantes sortantes ou entrantes doivent fonctionner.
Le LAN n'a donc plus d'adresse publique, ce qui peut peut-être gêner certains serveurs, mais peut-être pas. Y a-t-il un autre moyen de faire ou est-ce que c'est la bonne (le NTP je suppose) ?
#2.16
Je ne comprend pas très bien pourquoi tu cherche à casser l'intérêt d'IPv6 et te limiter en type d'adresses avec du NAT66. Pour information, sous linux, un port réseau peut avoir jusqu'à 16 adresses simultanément (aucune idée pour windows). Tu as au minimum une adresse de lien local qui se crée toute seule et des adresses ULA ou globales qui peuvent être ajoutée de plusieurs manières en même temps.
En laissant IPv6 fonctionner en SLAAC, les mécanismes de roaming intégrés fonts que la transition d'un routeur à un autre en fonction de la qualité de service s'opère automagiquement.
Tu peux ainsi cumuler des adresses locales ULA pour les services internes et des adresses globales pour tout le reste: avec IPv6, tu as le beurre, l'argent du beurre et les faveur du crémier ou de la crémière (c'est selon).
Si tu cherche à protéger les machines du LAN, le firewall des routeurs est là pour cela. Pour anonymiser le traffic http, tu peux utiliser un proxy web à qui tes clients peuvent se connecter via une adresse ULA indépendante de tes adresses globales.
Là encore, pas besoin de s'encombrer avec un NAT66 qui n'a pas pour vocation de protéger quoi que ce soit et qui va donc te créer plus de problèmes que de gains.
Côté serveurs, s'ils doivent être accessibles de l'extérieur, il faut à un moment donné une ou des adresses globales et fixes pour les renseigner dans un DNS. Les serveurs peuvent se voir attribuer des adresses fixes de services en plus des adresses qui seraient auto attribuées par la configuration automatique. Cela permet aux serveurs d'utiliser l'adresse aléatoire pour les connexions sortantes et l’adresse fixe pour être contactés.
#2.17
Je ne comprends pas comment le SLAAC peut fonctionner, il faudrait envoyer plusieurs RA, un par préfixe (je sais pas si on peut faire ça) ? Ca va vraiment créer une adresse par préfixe sur chaque machine ? Si oui, j'ai l'impression que je vais tomber plus ou moins vite sur une implémentation à la con qui supportera pas plusieurs préfixes.
Je ne vois pas non plus comment va être choisi la connexion de sortie. Si une machine à une adresse par préfixe, c'est donc elle qui va choisir laquelle utiliser et donc par où elle va sortir, mais sur quel critère ? Elle n'a aucune information sur les capacités, l'état de charge et de fonctionnement des connexions de sortie. Tu parles de roaming automagique, tu peux préciser (et ça a l'air aussi dépendant de la qualité de l'implémentation) ?
Et non je ne cherche pas pour l'instant à protéger les machines de l'extérieur, mais déjà de faire un truc qui fonctionne de la meilleure manière possible, ensuite je m'attaquerai aux firewalls.
Historique des modifications :
Posté le 02/07/2024 à 10h48
Pardon, c'était NPT (Network Prefix Translation), pas NTP.
Je ne comprends pas comment le SLAAC peut fonctionner, il faudrait envoyer plusieurs RA, un par préfixe ( je sais si on peut faire ça) ? Ca va vraiment créer une adresse par préfixe sur chaque machine ?
Je ne vois pas non plus comment va être choisi la connexion de sortie. Si une machine à une adresse par préfixe, c'est donc elle qui va choisir laquelle utiliser et donc par où elle va sortir, mais sur quel critère ? Elle n'a aucune information sur les capacités, l'état de charge et de fonctionnement des connexions de sortie. Tu parles de roaming automagique, tu peux préciser ?
Et non je ne cherche pas pour l'instant à protéger les machines de l'extérieur, mais déjà de faire un truc qui fonctionne de la meilleure manière possible, ensuite je m'attaquerai aux firewalls.
Posté le 02/07/2024 à 10h50
Pardon, c'était NPT (Network Prefix Translation), pas NTP. Et pour le NAT66 j'ai dit que j'avais testé mais que c'était effectivement pas élégant.
Je ne comprends pas comment le SLAAC peut fonctionner, il faudrait envoyer plusieurs RA, un par préfixe ( je sais si on peut faire ça) ? Ca va vraiment créer une adresse par préfixe sur chaque machine ?
Je ne vois pas non plus comment va être choisi la connexion de sortie. Si une machine à une adresse par préfixe, c'est donc elle qui va choisir laquelle utiliser et donc par où elle va sortir, mais sur quel critère ? Elle n'a aucune information sur les capacités, l'état de charge et de fonctionnement des connexions de sortie. Tu parles de roaming automagique, tu peux préciser ?
Et non je ne cherche pas pour l'instant à protéger les machines de l'extérieur, mais déjà de faire un truc qui fonctionne de la meilleure manière possible, ensuite je m'attaquerai aux firewalls.
Posté le 02/07/2024 à 10h51
Pardon, c'était NPT (Network Prefix Translation), pas NTP. Et pour le NAT66 j'ai dit que j'avais testé mais que c'était effectivement pas élégant.
Je ne comprends pas comment le SLAAC peut fonctionner, il faudrait envoyer plusieurs RA, un par préfixe (je sais pas si on peut faire ça) ? Ca va vraiment créer une adresse par préfixe sur chaque machine ?
Je ne vois pas non plus comment va être choisi la connexion de sortie. Si une machine à une adresse par préfixe, c'est donc elle qui va choisir laquelle utiliser et donc par où elle va sortir, mais sur quel critère ? Elle n'a aucune information sur les capacités, l'état de charge et de fonctionnement des connexions de sortie. Tu parles de roaming automagique, tu peux préciser ?
Et non je ne cherche pas pour l'instant à protéger les machines de l'extérieur, mais déjà de faire un truc qui fonctionne de la meilleure manière possible, ensuite je m'attaquerai aux firewalls.
Posté le 02/07/2024 à 10h52
Pardon, c'était NPT (Network Prefix Translation), pas NTP. Et pour le NAT66 j'ai dit que j'avais testé mais que c'était effectivement pas élégant. Le NPT l'est beaucoup plus.
Je ne comprends pas comment le SLAAC peut fonctionner, il faudrait envoyer plusieurs RA, un par préfixe (je sais pas si on peut faire ça) ? Ca va vraiment créer une adresse par préfixe sur chaque machine ? Si oui, j'ai l'impression que je tomberai un jour sur une implémentation à la con qui supportera pas plusieurs préfixes.
Je ne vois pas non plus comment va être choisi la connexion de sortie. Si une machine à une adresse par préfixe, c'est donc elle qui va choisir laquelle utiliser et donc par où elle va sortir, mais sur quel critère ? Elle n'a aucune information sur les capacités, l'état de charge et de fonctionnement des connexions de sortie. Tu parles de roaming automagique, tu peux préciser ?
Et non je ne cherche pas pour l'instant à protéger les machines de l'extérieur, mais déjà de faire un truc qui fonctionne de la meilleure manière possible, ensuite je m'attaquerai aux firewalls.
Posté le 02/07/2024 à 10h59
Pardon, c'était NPT (Network Prefix Translation), pas NTP. Et pour le NAT66 j'ai dit que j'avais testé mais que c'était effectivement pas élégant. Le NPT l'est beaucoup plus.
Je ne comprends pas comment le SLAAC peut fonctionner, il faudrait envoyer plusieurs RA, un par préfixe (je sais pas si on peut faire ça) ? Ca va vraiment créer une adresse par préfixe sur chaque machine ? Si oui, j'ai l'impression que je tomberai un jour sur une implémentation à la con qui supportera pas plusieurs préfixes.
Je ne vois pas non plus comment va être choisi la connexion de sortie. Si une machine à une adresse par préfixe, c'est donc elle qui va choisir laquelle utiliser et donc par où elle va sortir, mais sur quel critère ? Elle n'a aucune information sur les capacités, l'état de charge et de fonctionnement des connexions de sortie. Tu parles de roaming automagique, tu peux préciser ?
Et non je ne cherche pas pour l'instant à protéger les machines de l'extérieur, mais déjà de faire un truc qui fonctionne de la meilleure manière possible, ensuite je m'attaquerai aux firewalls.
Posté le 02/07/2024 à 11h35
Pardon, c'était NPT (Network Prefix Translation), pas NTP. Et pour le NAT66 j'ai dit que j'avais testé mais que c'était effectivement pas élégant. Le NPT l'est beaucoup plus.
Je ne comprends pas comment le SLAAC peut fonctionner, il faudrait envoyer plusieurs RA, un par préfixe (je sais pas si on peut faire ça) ? Ca va vraiment créer une adresse par préfixe sur chaque machine ? Si oui, j'ai l'impression que je vais tomber plus ou moins vite sur une implémentation à la con qui supportera pas plusieurs préfixes.
Je ne vois pas non plus comment va être choisi la connexion de sortie. Si une machine à une adresse par préfixe, c'est donc elle qui va choisir laquelle utiliser et donc par où elle va sortir, mais sur quel critère ? Elle n'a aucune information sur les capacités, l'état de charge et de fonctionnement des connexions de sortie. Tu parles de roaming automagique, tu peux préciser ?
Et non je ne cherche pas pour l'instant à protéger les machines de l'extérieur, mais déjà de faire un truc qui fonctionne de la meilleure manière possible, ensuite je m'attaquerai aux firewalls.
#2.8
#3
Historique des modifications :
Posté le 01/07/2024 à 10h25
J’ai eu pendant 2 ans un Sony Xperia V (rose, un cadeau de ma copine de l’époque), et franchement j’étais sur le cu.. devant la prouesse des ingénieurs de chez Sony qui avaient réussi à sortir un smartphone avec un rating IP57 (dust/water resistant up to 1m for 30 min) avec batterie amovible, qu’on pouvait remplacer aussi facilement que sur un Nokia 3310 (la brique) simplement en ouvrant le couvercle arrière du téléphone.
Le Sony Xperia V est sorti en… 2012...
Sony Xperia V @ GSMArena
Quand on veut, on peut…