Étude de cas: Un problème à l'échèle nationale
Il y a quelques années, en 2013 pour être plus précis, je travaillais au sein d'une grande entreprise de quelques dizaines de milliers d'employés. Pour une entreprise de télécommunication, une entreprise de cette envergure représente une mine d'or.
À cette époque, comme aujourd'hui, on voyait déjà que 2 plateformes mobile émergeaient: iOS et Android. Pour ma part, j'utilisais "Windows Phone". Eh oui, j'étais un fidèle partisant de la plateforme de Microsoft. Il ne faut pas m'en vouloir, j'ai toujours été un fan de .NET et C# et c'est la plateforme par excellence qui me permettait de m'amuser et créer mes petits projets "on the side".
Mais bon dans cette entreprise, j'étais un mouton noir. Nous étions une dizaine seulement à avoir des Windows Phone. Les autres, avaient encore de vieux Blackberry et les plus "chanceux", des iPhones. Quelques personnes utilisaient Android, mais la plateforme était encore "officieuse" au sein de l'entreprise.
Il s'adonne que depuis des mois, Michel (moi) et son irréductible Windows Phone, nous "battons" contre des collègues et des politiques dans l'entreprise pour faire des changements au niveau firewall. Pourquoi?
Windows Phone est un appareil Microsoft. Les appareils mobiles qui se connectent à Exchange utilisent un protocol qui s'appelle ActiveSync. Hors, j'avais un problème avec mon téléphone: quand je configurais mon téléphone pour recevoir mes courriels d'entreprise, mon téléphone devenait chaud et j'étais obligé de maintenir le téléphone branché pour pouvoir faire la journée. Je me suis rendu compte, par contre, lorsque j'étais branché au WiFi dans le laboratoire (pas le même firewall), tout allait bien. Mes collègues administrateurs d'Exchange, la plateforme de courriel, réfutaient mon problème et disait "il n'y a que toi qui a le problème, si le problème existait, ceux qui ont des iPhone aurait aussi le problème".
J'ai alors entrepris de comprendre à fond le protocol Exchange ActiveSync jusqu'à ce que je découvre que la cause du problème. Vulgarisé simplement, le téléphone contacte le serveur Exchange et demande "Est-ce que j'ai des courriels?" et s'il n'y en a pas, le téléphone garde la connection ouverte "ok, tu me diras quand il en aura"... et quand un courriel arrive, le serveur retourne un message "j'ai de quoi pour toi!", et bien-sûr, le téléphone va chercher le courriel reçu. C'est ainsi, en théorie, instantané. Hors, j'ai réussi à prouver que lorsqu'on passait par le réseau externe (donc le firewall), le Time-to-live (TTL) de la connection, c'est-à-dire, le temps que la connection peut rester ouverte, était de seulement 60 secondes. Le protocol Active-Sync est intelligent et se "protège" contre ça. Pour déterminer le temps maximum, il essaie pour 45 minutes. Si la connection n'est pas maintenue pour 45 minutes, il essaie 22 minutes... ensuite 11 minutes, jusqu'à descendre à 1 minute. Autrement dit, lorsqu'un téléphone était connecté au serveur courriel de l'entreprise, le téléphone interrogeait le serveur Exchange un peu plus de fois par heure au lieu d'une ou 2 fois.
Fier de ma trouvaille, je tentai une nouvelle intervention auprès de mes collègues et puisque nous étions si peu à avoir des Windows Phone, je n'ai pu les convaincre de faire un tel changement (pour eux c'était une "expérience" et non un besoin qui méritait d'impliquer l'équipe de sécurité et de réseaux).
Un jour, le BlackBerry Z10 arrive sur le marché. Un BlackBerry? Eh oui, cette plateforme, autrefois fierté Canadienne, qui tentait, tant bien que mal de revenir d'entre les morts. Un géant des télécommunication canadienne, dont je taierai le nom dans cet article (il n'y en a avait que 3 à l'époque, tentez votre chance!) a offert au grand patron des TI d'essayer le tout nouveau BlackBerry Z10. Ce patron aime particulièrement les technologies, n'était pas peu fier d'être un des premier au Canada à pouvoir essayer le nouvel appareil de BlackBerry.
Mais, comble de malheur. Le téléphone, tout neuf, ne parvient pas à tenir une demie-journée et le téléphone est continuellement chaud.
Donc le jour où j'ai eu vent du problème avec son BB Z10, j'ai rapidement fait 1+1=2. De fil en aiguille, le patron en question me fait venir dans son bureau et me demande de lui faire part des mes trouvailles et de ce fait, d'investiguer le problème: "Ça fait 2 fois que la compagnie de cellulaire remplace l'appareil et il a toujours le même problème, la batterie dure que quelques heures". Ce n'était pas l'intention, mais avec un peu de capital polique, je me sentais mieux outillé pour faire bouger les choses! J'avais une mission!
J'ai donc monter un petit lab pour reproduire le problème. J'ai vu rapidement en analysant les traces Wireshark (un sniffer réseau) que non seulement le Blackberry Z10 avait bel et bien le même problème que Windows Phone, c'était pire. Ce dernier essayait de se connecter au 30 secondes, soit 120 fois par heure, même si techniquement la connection restait ouvert pour 60 secondes. Ayant l'aval du grand patron, j'ai pu enfin faire changer le TTL sur les connections à 46 minutes (puisque 45 minutes était le maximum recommandé par ActiveSync). Savez-vous quoi? Le problème était réglé... ou presque.
Mais pourquoi les iPhones n'avaient pas de problème?
Pendant mon investigation, j'ai eu accès à un iPhone corporatif et j'ai pu analyser les traces WireShark. Contrairement à ce que mes collègues croyaient, ça ne fonctionnait pas non plus avec le iPhone. Les gens croyait que la synchronisation "push notification" avec ActiveSync fonctionnait. Si on envoyait un courriel, il pouvait se passer entre 10 et 15 minutes avant que le courriel soit reçu sur le iPhone. Ce qui déjouait les utilisateurs, c'est que chaque fois que les gens ouvraient leur iPhone, le petit chiffre sur l'icon courriel montait pour indiquer que des courriels arrivaient. La vérification avait donc lieu, en temps réel, quand la personne ouvrait son téléphone. Et pourquoi la batterie ne se vidait pas? Il y a probablement un p'tit géni chez Apple qui s'est rendu compte du problème. Lors que le téléphone ne parvenait pas à maintenant une connection avec le serveur, il n'allait pas plus bas que 15 minutes au lieu de vérifier chaque 60 ou 30 secondes.