chore(release): v0.6.0
This commit is contained in:
@@ -6,6 +6,44 @@ Ce projet suit le [Versionnage Sémantique](https://semver.org/lang/fr/).
|
||||
|
||||
---
|
||||
|
||||
## [0.6.0] — 2026-09-01
|
||||
|
||||
### Ajouté
|
||||
- **Test de handshake réel, sans monter le tunnel.** Le diagnostic s'arrêtait au constat « le port
|
||||
UDP ne rejette rien », qui est le maximum qu'une sonde aveugle puisse dire : un serveur WireGuard
|
||||
ignore silencieusement tout paquet non authentifié, si bien qu'un port non redirigé, une clé
|
||||
inconnue du serveur et un serveur en parfaite santé produisent exactement la même absence de
|
||||
réponse. Le tunnel n'étant pas monté, les étapes suivantes étaient sautées et le rapport
|
||||
concluait « chaîne validée » sur une configuration qui n'avait aucune chance de négocier.
|
||||
WGSecure construit désormais un vrai message d'initiation et interprète la réponse : il distingue
|
||||
un handshake complet, une clé pré-partagée attendue, en trop ou différente, un cookie anti-déni
|
||||
de service, un port fermé et un silence complet — sans ouvrir de tunnel ni demander de privilèges.
|
||||
- **Détection du filtrage sur port source.** Quand le serveur reste muet, une seconde tentative
|
||||
part depuis le port du serveur. S'il répond alors, c'est qu'un équipement en chemin n'accepte le
|
||||
trafic que si le port source égale le port de destination — une règle courante sur FortiGate,
|
||||
dont l'objet Service porte un `udp-portrange 51820:51820`. Un client WireGuard émettant depuis un
|
||||
port aléatoire ne peut jamais la satisfaire, et rien dans les journaux ne le disait.
|
||||
|
||||
### Modifié
|
||||
- **Fenêtre d'administration ramenée à 720 × 600** (minimum 640 × 520) : le découpage en
|
||||
sous-onglets a supprimé l'empilement qui imposait une grande fenêtre.
|
||||
- **Encarts d'introduction retirés au-dessus des sous-onglets**, où ils répétaient ce que les
|
||||
sous-onglets annoncent déjà. Ceux placés dans chaque sous-onglet sont conservés.
|
||||
|
||||
### Corrigé
|
||||
- **Verdict trompeur quand le tunnel est inactif.** « Chaîne validée jusqu'au tunnel » laissait
|
||||
croire que tout avait été vérifié, alors que les étapes sautées sont précisément celles qui
|
||||
échouent quand un tunnel refuse de négocier. Le rapport annonce maintenant « rien de bloquant
|
||||
détecté, mais le tunnel est inactif » et nomme les étapes non évaluées.
|
||||
- **Causes du handshake manquant** : le port UDP du serveur figure désormais parmi les pistes
|
||||
citées, un port erroné ne produisant aucune erreur visible.
|
||||
|
||||
### Technique
|
||||
- Nouveau module `app/core/wg_handshake.py` : implémentation de la poignée de main
|
||||
Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s du protocole WireGuard v1. Aucun état n'est conservé, la
|
||||
session négociée est jetée aussitôt et le serveur traite l'initiation comme celle d'un pair qui
|
||||
se reconnecte.
|
||||
|
||||
## [0.5.0] — 2026-09-01
|
||||
|
||||
### Ajouté
|
||||
|
||||
Reference in New Issue
Block a user