Bonjour les moules,
Je vous explique mon problème: dans les résidences de mon école d'ingénieur, on accède au réseau par un VPN cisco. L'année (scolaire) dernière, tout passait bien, on pouvait tout simplement utiliser ça: http://www.unix-ag.uni-kl.de/~massar/vpnc/
Cette année, les administrateurs on eu la merveilleuse idée de passer de l'encryption 3DES (qui marchait très bien avec le client libre) à NULL (pas d'encryption, tout passe en clair...) pour des raisons de "performances" (dans ce cas, je vois pas l'intérêr d'un VPN, mais bon...)
Quelqu'un a alors tenté d'implémenter le support de NULL pour le client libre. Il a posté un patch sur la ML ici: http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2006-Jan(...)
Le patch ne marche pas, personne n'a l'air de savoir pourquoi. Résulat au jour d'aujourd'hui: obligé de passer par un client propriétaire qui marche pas partout. Je m'en était contenté jusqu'à aujourd'hui, mais je compte passer à OpenBSD, et apparament le client propriétaire n'y fonctionne pas. J'ai donc décidé de faire fonctionner ce *** de patch.
[Détails techniques inintéressants]
J'ai déjà trouvé un premier bug (taille de bloc du cryptage "null" (!) trop grande => dépassement de tampon qui corrompt l'entête IP originale - quand ça segfaulte pas). Mais même après avoir corrigé ça, ça marche toujours pas. A première vue (au vu des réponses du serveur), il n'y a pas de "nonce" dans l'entête VPN pour l'encryption "null" - le problème, c'est qu'apparment vpnc (le client libre) considère que taille du nonce = taille de bloc de l'algo de chiffrement != 0 (c'est le cas dès que les paquets sont cryptés, mais dès que c'est non crypté, taille de bloc = 8 et taille du nonce = 0) et que découpler ces deux variables va être... pour le moins épique.
[/Détails techniques]
Donc, avant de me lancer dans un code qui n'a aucune chance de fonctionner, j'aimerais vérifier que mon hypothèse est bonne en capturant les paquets"tunnelés". Et le hic est là, ça marche pas du tout :p
En gros, un paquet typique passe par tun0, est encapsulé en un paquet ESP, puis passe par eth0 (enfin, je pense, il doit pas passer par télépathie ;)). Quand j'écoute tun0 avec tcpdump, je vois effectivement un paquet ICMP... qui disparait ensuite mystérieusement (rien dans eth0, et aucun paquet ESP où que ce soit - eth0 ou tun0 - à part la réponse du serveur). Quant à strace, hors de question: le client proprio fait tout en espace noyau...
Donc, si que que ce soit a une idée du pourquoi mon paquet se sublime et comment le rattraper, je suis toute ouïe...
# Oubli...
Posté par Moonz . Évalué à 2.
Soit une table de routage über-obfuscated et une adresse IP tout ce qu'il y a de plus conventionnel. Y a t'il un moyen simple (sans sortir la grosse artillerie genre tcpdump, qui me semble pas vraiment adapté à ça :)) de savoir quelle règle s'applique à cette adresse ?
# Je me réponds à moi-même
Posté par Moonz . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.