Connectivité internet défaillante

Donc, vous êtes un paquet mis en mouvement par l’action de l’utilisateur sur la touche Entrée de son navigateur web.

Ce paquet est une requête TCP SYN (synchronization), ou start-of-session. Comme il est destiné à Internet, le paquet a une adresse IP non locale ; et donc, la première chose que le poste de travail doit faire est de trouver une passerelle ou un routeur vers le monde extérieur. Faute de quoi, le paquet SYN ne peut pas quitter l’ordinateur.

Dans cet exemple, cette passerelle est le pare-feu Internet local, spécifié dans la configuration TCP/IP de l’ordinateur. Supposons que c’est la première fois que l’ordinateur communique avec ce pare-feu.

LAN Local

Il doit localiser le pare-feu sur le LAN local en utilisant le protocole ARP, en diffusant une requête ARP contenant l’adresse IP du pare-feu. Le pare-feu réagit par une réponse ARP donnant son adresse MAC. L’ordinateur poste de travail est maintenant prêt à acheminer la requête SYN vers le pare-feu, son premier “tronçon” sur la route de sa destination finale. Pour vérifier que le poste de travail peut faire cela, examinez sa table ARP (par exemple, en utilisant la commande « arp -a » dans une ligne de commande Windows). S’il existe une entrée pour l’adresse IP du pare-feu, ARP a réussi. Un autre test consiste à envoyer un ping au pare-feu, pour s’assurer d’une connexion sans entrave entre le poste de travail et sa passerelle.

Digital Subscriber Line (DSL) ou T1

Dans la peau d’un paquet, vous venez juste de quitter l’ordinateur et d’arriver au pare-feu. Prochaine étape ? Le pare-feu lui-même a une passerelle par défaut configurée, laquelle est atteinte par un moyen de communication, comme une connexion Digital Subscriber Line (DSL) ou T1. Il y aura une procédure MAC pour ce type ou moyen de connexion, donc vous pouvez répéter le même processus ARP qu’au premier tronçon : le routeur devrait avoir une entrée ARP identifiant l’adresse MAC de l’unité du prochain tronçon, comme un modem DSL ou un routeur T1, ou quelqu’autre unité d’accès à Internet (Internet access device, IAD). Si l’entrée ARP du pare-feu existe, le pare-feu sait comment atteindre son prochain tronçon. La question est à présent : vous laissera-t-il, vous, le paquet, y aller ?

DHCP

La réponse dépend des règles du pare-feu, que nous allons examiner. Une pratique courante veut que l’on ne permette l’accès à Internet qu’à partir de certaines adresses IP autorisées, comme celles enregistrées par le Dynamic Host Configuration Protocol (DHCP). Si tel est le cas, l’adresse IP de votre ordinateur se trouve-t-elle dans la liste des utilisateurs autorisés ? Une autre pratique est de ne permettre qu’à certains protocoles, tels que HTTP (port 80) et HTTPS (port 443), de sortir au travers du pare-feu. Le site web de destination de l’utilisateur fonctionne-t-il sur un numéro de port non standard (indiqué par :xxx après la partie nom d’hôte de l’URL, comme dans http://www.example.com:8080). Si le pare-feu a des règles qui bloquent la progression du paquet vers l’extérieur, il ne dépassera pas ce point. Souvent, vous pouvez examiner le log du pare-feu pour voir s’il a enregistré une transgression de la règle d’accès sortant.

Continuez à chevaucher le paquet sur tous les tronçons jusqu’à la destination. Cependant, dans cet exemple, un fois le FAI atteint, le problème n’est probablement plus de votre ressort. Mais vous savez que votre réseau n’est pas fautif.

Vérifiez donc que votre FAI est opérationnel, qu’il ne bloque pas votre trafic sortant, et que le serveur web de destination est tout disposé à accepter des connexions provenant de votre adresse IP source. Pour cela, il faut généralement contacter des intervenants tiers. Mais, munis des preuves que les paquets quittent votre réseau, il vous sera plus facile de convaincre ces interlocuteurs de mener leur propre enquête.

Traceroute

Cet exemple, volontairement simplifié, illustre la technique du “raisonner comme un paquet”. Dans une situation concrète, vous devriez suivre le même raisonnement avec le paquet DNS lookup qui précède la requête SYN, et peut-être même songer au processus DHCP qui aurait pu précéder DNS. Durant cette opération, servez-vous des outils réseau existants : traceroute pour vérifier le chemin suivi par votre paquet, nslookup pour confirmer la résolution DNS que vous prédisez, et ping pour confirmer qu’une destination est atteignable. Songez aussi au chemin de retour qu’un paquet de réponse suivrait, dans le cas où votre paquet sortant réussirait son voyage. Ce paquet peut être bloqué ou dérouté parce que, par exemple, votre adresse source est en liste noire. Ou bien, il pourrait être bloqué par votre pare-feu à son arrivée à la frontière de votre réseau.

C’est la pensée qui compte

Après avoir essayé plusieurs fois de raisonner comme un paquet, vous constaterez que cette technique détecte des problèmes réseau simples mais cachés. Il est facile de négliger des principes de réseau basiques, comme les communications au niveau MAC et les règles de routage. En renforçant votre connaissance des couches basses de TCP/IP et en suivant le chemin d’un paquet, pas à pas, vous éluciderez presque toujours le mystère le plus épais. Et, par la même occasion, vous aiguiserez vos talents de spécialiste réseau.

Pour aller plus loin avec les experts @ITPROFR

5. Network Connectivity Tester (netdiag.exe) · iTPro.fr

Tester un port UDP via TelNet, Trucs & Astuces @ITPROFR · iTPro.fr