C’est le principe même des règles globales qui est pris en défaut.
Je n’ai par exemple aucune raison de tout autoriser vers un masque 255.255 ni d’interdire une adresse de broadcast 224. en particulier (pourquoi pas toutes?).
Je n’ai personnellement jamais réussi à faire fonctionner une règle globale d’exclusion.
Concernant le réseau local, s’il est familial, aucune raison de principe d’en faire une règle d’interdiction, confinons-nous, hors cas particuliers à gérer au cas par cas, à allow ou ask.
Je me contenterais, outre les règles globales prédéfinies, d’écrire 2 règles globales:
tcp/udp, out, ip source et ip dest =lan, source port et source dest =all, allow
même chose à suivre, tcp/udp, in
où lan = la zone réseau 192.168.1.1-192.168.1.255:
toutes communications autorisées si à la fois la source et la destination en sont le réseau local (cela ne confère pas pour autant, en ntfs et même en fat32 le droit de faire ce que l’on veut sur un réseau local, puisqu’il y faut des autorisations de partage windows).
Maintenant, c’est peut-être moche pour toi s’il y en a beaucoup, mais je me contenterais de faire de tes jeux non pas des règles globales, mais des règles d’application:
jeu tartempion, udp out, ip source 192.168.1.1, ip dest UNIQUEMENT CELLES PERMETTANT LE JEU, port source any, port dest 53, allow.
Une règle globale est dangereuse.
De même, on n’a aucune raison, même si localhost n’est en théorie pas davantage routable que le lan 192.168, de tout y autoriser: je me contente de faire une règle là aussi non pas globale, mais d’application pour ce qui ne fonctionne pas sans:
exemple: j’ai une règle identique pour Kompozer et Firefox, autorisant tcp out vers localhost, mais dans le même temps, j’ai des règles d’interdiction pour ce même localhost (udp out vers) pour explorer et svchost:
je n’ai rien inventé d’autre que le “trial and error”, tout ce qui n’est pas strictement indispensable au fonctionnement d’un logiciel est systématiquement interdit dès l’alerte, pour tester aussitôt et rétablir si besoin.
Maintenant, effectivement, si tu joues à plein de jeux (ils sont un risque de sécurité), il n’y a pas de solution 100% pratique, puisque les mettre en zone de confiance est tout de même un peu hara-kiri:
la seule solution réellement sécuritaire est le cas par cas, mais bien sûr, si ça fonctionne parfaitement une fois les réglages propres à chaque application gérés, c’est avant un peu de temps “perdu”.
Pour schématiser, tes règles globales (quand elles ne sont pas malsaines, le moins de règles globales est le mieux) ne fonctionnent pas pour une ou plusieurs des raisons suivantes:
-opposition à une règle d’applications du firewall (même si elle est générique windows et ne concerne pas un jeu en particulier): pour les règles “out”, les règles d’application sont prioritaires
-syntaxe déficiente de la règle globale: les règles sont booléennes, il est très difficile dans ces conditions d’interpréter correctement une règle comportant soit une exclusion, soit à la fois des entrées et sorties.
Ainsi, la règle 192.168.1.1 est foireuse puisque, si on voulait l’appliquer (et il ne faut surtout pas le faire), il conviendrait d’écrire, sans exclusion:
source ip = 192.168.1.1, dest ip = tout, udp, out, port source any, port dest 53, allow
Je clos personnellement l’essentiel de ce problème par une règle d’application svchost:
tcp/udp, out, ip source any, ip dest LES SEULES IP DE MON FAI, port source any, port dest 53, allow.
Et nous constatons apparemment, comme je le pressentais, que les règles globales hamachi (hormis évidemment celles permettant à hamachi de tourner) ne servent à rien, puisqu’elles ne constituent qu’un “encapsulage” de la communication sur internet mais que, arrivé ou partant de “chez toi”, et à l’instar de ce qui se passe pour un serveur http/ftp avec redirection d’ip dynamique (NoIp…), c’est bien l’ip locale (192.168.1.1) qui est demanderesse, et pas hamachi (ou les ports NoIp dans l’exemple que j’ai choisi une fois qu’ils ont franchi le routeur).