Samedi, 13 janvier 2007
Bout Du Tunnel sur SourceForge
Dimanche, 10 décembre 2006
Bout du Tunnel v1.3
Une nouvelle version dans laquelle le protocole de communication a été totalement remanié pour augmenter les performances (notamment la latence). Ainsi cette version n'est plus compatible avec les précédentes.
De plus cette version est désormais disponible en français et en anglais. Le basculement est automatique suivant le paramètrage du système mais il reste possible de forcer la langue en utilisant le fichier de configuration (service/culture="fr|en")
Les plateformes utilisées:
Microsoft .NET v2.0.50727
Mono v1.2.1
Les binaires:
bdt.bin.1.3.mono.zip
bdt.bin.1.3.dotnet.zip
Les sources:
bdt.src.1.3.zip
Lundi, 27 novembre 2006
Bout du Tunnel v1.2.2522
Une version de correction pour les bugs suivants:
La saisie des informations d'authentification sur un proxy (lorsque le login/password est refusé par le serveur) utilisait du code natif pour la gestion de la console. Désormais le Framework 2 propose toutes les fonctions nécessaires, ce qui permet d'assurer la portabilité (grâce à Mono) de BDT sur les plateformes autres que Windows.
Il était possible d'afficher plusieurs instances de la fenêtre de configuration sans pour autant affecter la stabilité de l'application. Les 'TabIndexes' étaient mal configurés.
Un 'Ballon Tip' s'affiche désormais lorsque le client graphique parvient à se connecter, ce qui est pratique pour les feignants comme moi.
Le Makefile Mono a été modifié.
Les plateformes utilisées:
Microsoft .NET v2.0.50727
Mono v1.2.1
Les binaires:
bdt.bin.1.2.2522.mono.zip
bdt.bin.1.2.2522.dotnet.zip
Les sources:
bdt.src.1.2.2522.zip
Dimanche, 19 novembre 2006
Bout du Tunnel v1.2
Une nouvelle version est disponible, cette dernière comprend un client graphique. Le code réseau a été remanié pour gérer dynamiquement les différents délais liés au polling (à cause du modèle requête/réponse du protocole HTTP) Le code a été revu et modifié pour faciliter les évolutions ultérieures. Tout ceci permet d'apporter un gain de performance notamment pour les protocoles basés sur HTTP.
L'arrivée ces derniers jours de la version 1.2 du Projet Mono a permis de pouvoir corriger les petits hacks de compatibilité qui étaient présents dans la version précédente. Le framework 2.0 est désormais totalement supporté dans Mono au niveau core, malheureusement certaines classes de Windows.Forms ne sont pas encore implémentées comme BindingList ou BindingSource, de ce fait le client graphique n'est pas encore utilisable avec mono.
Cette version reste compatible avec la précédente au niveau protocole de communication, mais il est recommandé de procéder à une mise à jour pour bénéficier des différentes améliorations disponibles.
Comme précédemment, le code source est strictement identique pour les différents binaires, et ce sans le moindre 'define'. Les Makefile ont été totalement revus.
Les binaires Mono et .NET sont compatibles:
Un client Mono peut se connecter à un serveur .NET et inversement.
Un binaire Mono peut s'exécuter sous le framework .NET ou Mono.
Un binaire .NET peut s'exécuter sous le framework .NET ou Mono.
(Exception faite du client graphique qui ne s'exécute que sous .NET)
Les plateformes utilisées:
Microsoft .NET v2.0.50727
Mono v1.2
Les binaires:
bdt.bin.1.2.mono.zip
bdt.bin.1.2.dotnet.zip
Les sources:
bdt.src.1.2.zip
Quelques images du client graphique:
Dimanche, 2 avril 2006
Bout Du Tunnel v1.1
Bdt est désormais compilable et utilisable avec le framework open source du Projet Mono, ce qui lui permet notamment de pouvoir tourner sous linux.
Quelques modifications ont été apportées pour permettre une utilisation sous .NET et Mono.
- L'implémentation du générateur pseudo aléatoire est différente suivant les plateformes, or une petite routine de cryptage utilisait justement ce générateur. Ceci implique que cette version n'est plus compatible avec les précédentes au niveau du protocole de communication.
- Dans les deux implémentations, Il n'est pas possible de forcer un proxy particulier pour l'objet HttpClientChannel (remoting), je le fais donc par introspection (c'est mal). Dans les deux implémentations, le nom du membre privé associé diffère d'un underscore.
- Dans l'implémentation de Mono, il est impossible de passer "null" pour le paramètre 'properties' lors de la création d'un objet HttpChannel (remoting). Avec .NET ça marche.
- Lorsque l'on utilise un Generic.Dictionary pour passer ces paramètres, si tous ne sont pas renseignés, on reçoit une exception dans l'implémentation Mono. Avec .NET, des vérifications sont effectuées (.Contains)
- L'objet SortedDictionnary (Generic) n'est pas implémenté dans Mono
- Les accents posent problème. En changeant l'encodage du fichier de utf-8 vers unicode, pas mal d'entre eux sont résolus, mais pas tous. J'ai donc enlevé tous les accents.
- L'implémentation mono ne supporte pas la gestion NTLM, et la récupération des informations de connexion via Internet Explorer (ce qui paraît bien compréhensible), pour les utilisateurs d'un proxy ISA Server, ou ceux derrière un domaine, l'implémentation .NET (côté client) est à privilégier.
A noter que le code source est strictement identique pour les différents binaires, et ce sans le moindre 'define'. Des Makefile sont disponibles pour les deux plateformes pour tout compiler en ligne de commande.
Les binaires Mono et .NET sont compatibles:
Un client Mono peut se connecter à un serveur .NET et inversement.
Un binaire Mono peut s'exécuter sous le framework .NET ou Mono.
Un binaire .NET peut s'exécuter sous le framework .NET ou Mono (sauf le client pour l'instant, car l'opérateur d'égalité sur l'objet Uri ne semble pas encore implémenté dans Mono)
Les plateformes utilisées:
Microsoft .NET v2.0.50727
Mono v1.1.13.6
Les binaires:
bdt.bin.1.1.mono.zip
bdt.bin.1.1.dotnet.zip
Les sources:
bdt.src.1.1.zip
Lundi, 27 février 2006
Bout Du Tunnel v1.0.2249.39798
Les sources de Bdt ont été migrées en CSharp. Les futurs développements continueront sur cette base. De multiples collections ont été remplacées par des generics. Quelques logs ont été ajoutés au niveau du serveur.
les binaires:
bdt.bin.1.0.2249.39798.zip
les sources:
bdt.src.cs.1.0.2249.39798.zip
Jeudi, 23 février 2006
Bout Du Tunnel v1.0.2245.37863
Voici une nouvelle version de BDT:
+ ajout d'un encodage 'xor' minimaliste sur les données échangées entre le client et le serveur
Jetez un oeil sur SocksCap qui permet d'intercepter toutes les communications réseau de l'api WinSock pour les transmettre de façon transparente à un serveur Socks supportant les requêtes v5, en l'occurence le serveur Socks de BDT!
Les binaires:
bdt.bin.1.0.2245.37863.zip
Les sources:
bdt.src.vb.1.0.2245.37863.zip
Mercredi, 22 février 2006
Bout Du Tunnel v1.0.2241.28328
Au niveau du partage de l'accès à Internet, on distingue principalement deux grands systèmes : le système NAT (Network Address Translation) et le système Proxy. Un Proxy fonctionne au niveau 7 du modèle OSI, c'est à dire qu'il est capable d'interpréter et de modifier les informations du protocole sur lequel il travaille. Ainsi, il peut vérifier les données reçues de la part du serveur et en interdire ou modifier le contenu selon la politique choisie. L'utilisation d'un Proxy pour des protocoles critiques est donc souvent utile si on veut avoir une bonne vision de ce qui transite. Contrairement au Proxy, le système NAT est indépendant des applications utilisées. On peut donc faire passer la plupart des protocoles de manière transparente.
De nombreuses entreprises choisissent de recourir à des serveurs Proxy. Dédiés à un protocole particulier, ils sont capables d'interpréter les flux et notamment de mettre en cache les informations. On diminue ainsi le trafic et on augmente la bande passante. On se limite souvent à l’utilisation d’un Proxy HTTP puisque c’est très certainement le protocole le plus utilisé sur Internet. Par la même occasion, on prive les utilisateurs de nombreux services essentiels comme le ftp et le telnet.
Grâce à l’application BDT, il devient possible de contourner cette restriction en encapsulant tout le trafic réseau destiné à l’extérieur sous forme de messages HTTP. Ces messages nécessitent l’existence d’un pc de relais pour être décodés puis transmis au serveur final. Ce serveur relais est donc chargé de la gestion des connexions et de l’acheminement des données. La démocratisation des lignes xDSL et câble permet désormais de mettre en place facilement un tel relais.
L’application BDT est donc composée de deux parties : une portion client et une portion serveur. La portion client est chargée de créer un tunnel HTTP entre le client et la machine relais dans lequel sera déposé tout le trafic réseau. La portion serveur sera responsable de la communication entre ce tunnel et l’application serveur proprement dite.
La version initiale de BDT supporte plusieurs types de tunneling (HTTP, TCP, IPC) basés sur la technologie du .NET Remoting. Elle est inspirée du travail réalisé par Florent CUETO sur l'application SocksViaHTTP. La portion cliente propose un serveur Socks compatible v4, v4A et v5 pour faciliter l'interconnexion avec vos applications. Il reste également possible de créer des règles de 'forwarding' statiques pour les applications réticentes
Les binaires:
bdt.bin.1.0.2241.28328.zip
Les sources:
bdt.src.vb.1.0.2241.28328.zip
Schéma d'architecture
« Page précédente
(Page 4 de 4 sur 53 billets au total)
Commentaires