Tag Archive for Réseau

Faut-il fuir le DNS de Cloudflare ?

À cette question, la réponse simple semble être : oui.

Mais vous pouvez aussi me poser une autre question, comme :

« Euh, c’est quoi le DNS, et c’est quoi Cloudflare ? »

À cela, je vous ferai remarquer que vous posez deux questions et pas une seule. Mais bon, je suis de bonne humeur, et je répondrai aux deux.

Le DNS, c’est quoi ? 

Le DNS, c’est ça. Et grosso-modo, c’est l’annuaire d’Internet : vous tapez le nom www.apple.com et ça vous fait tomber sur le site web d’Apple, site hébergé sur une ou plusieurs adresses IP.

Comment ça se configure ?

La plupart du temps, vous n’avez pas à le configurer : il est automatiquement renvoyé par votre routeur Internet (votre box Internet, par exemple). Ce sont les entrées qu’on trouve dans la préférence Système Réseau > Avancé > DNS.

Préférence Réseau DNS

Bon alors, c’est quoi ton problème, GG ?

Il y a environ un an (le 1er avril 2018, pour être précis), Cloudflare, une société qui propose un service de cache d’informations sur le web (pour accélérer les accès aux sites) et de sécurisation (pour résister à des attaques type DDOS), a proposé son propre service DNS, utilisant les adresses IP 1.1.1.1 et 1.0.0.1. L’énooooooorme avantage était alors de proposer un service DNS théoriquement très rapide. Notez que Google propose aussi son propre service DNS depuis longtemps aux adresses 8.8.8.8 et 8.8.4.4 (mais perso, moins j’utilise les services de Google, mieux je me porte).

Sauf que.

Depuis quelques temps, je rencontrais énormément de lenteurs lors d’affichages de vidéo sur Twitter avec le client Twitterrific, autant sur Mac que sur iOS, mais uniquement connecté sur mon réseau Wi-Fi. Et forcément, ça m’agaçait un peu. J’ai tilté récemment, et j’ai posé la question sur Twitter. Tout juste après, je me suis rendu compte que vous étiez des milliers à avoir le même souci !

Dozens of us arrested development

J’ai donc remplacé mes DNS par ceux de Verisign (64.6.65.6, 64.6.64.6), et la situation s’est laaaaaargement améliorée. Et à priori, j’ai lu aussi quelques commentaires comme quoi les DNS de Cloudflare pouvaient être plus problématiques. J’ai aussi eu beaucoup de lenteurs lors du téléchargement de jeux sur PS4… Peut-être lié également, puisque ces contenus sont souvent mis en cache sur des CDN (Contents Distribution Networks), comme les serveurs d’Akamai.

Donc, méfiance : si vous utilisez les DNS de Cloudflare, pensez éventuellement à basculer vers d’autres serveurs (ceux de votre FAI, Google, Verisign ou autre) si vous rencontrez des lenteurs inexpliquées. Et n’hésitez pas à commenter sous ce billet si vous avez aussi constaté des soucis similaires.

Vous êtes administrateur Apple, Consultant, revendeur Apple ? Inscrivez-vous à Command-iT, la grande conférence des spécialistes Apple, les 15 et 16 mai au Grand Rex à Paris ! J’y animerai une conférence ainsi qu’un workshop ! Plus d’informations sur https://www.command-it.fr.

Mavericks et le transfert de fichiers qui ne finit jamais

Je viens de rencontrer sur le serveur d’un client un bug très curieux et particulièrement agaçant1. Après avoir installé un nouveau Mac mini en version serveur, j’ai déployé dessus l’excellent Rumpus, qui propose une interface super simple pour télécharger des fichiers en FTP, web, SFTP… Un logiciel éprouvé et à l’excellent support technique.

Sauf que là, quand on essaie de transférer des fichiers fichiers de 50 Mo ou plus depuis Rumpus, aucun ne s’achève. Le transfert commence correctement, puis…semble suspendu indéfiniment. Le téléchargement bloque à des endroits différents, et tout se passe comme si plus aucun paquet n’arrivait… sans que la liaison soit coupée. Mieux encore (ou pire, c’est selon), on peut continuer à contrôler le serveur à distance, les autres services fonctionnent correctement, et le même transfert en LAN ne pose aucun souci.

Après avoir mis hors de cause la ligne SDSL2 ou le reste de l’environnement réseau ou même Rumpus, puisque le souci arrivait également avec un transfert via scp, j’ai réussi à trouver un début de piste dans les Internets. En particulier, cette discussion sur le forum de JAMF (développeur de Casper) où est abordée une nouvelle fonction de Maverick : la validation ARP, expliquée plus en détails sur un blog de Cisco. Pour corriger le problème, il faut donc désactiver les réponses unicast ARP de Mavericks, en modifiant le fichier /etc/sysctl.conf (qui n’existe pas forcément par défaut) et en y rajoutant la ligne suivante :

net.link.ether.inet.arp_unicast_lim=0

Vous pouvez aussi télécharger un script shell qui fait ça fort bien pour vous sur Github. Téléchargez le script, modifiez les autorisations pour qu’il puisse être exécutable (chmod 755), et lancez le avec sudo.

Ceci fait, redémarrez votre Mac… Et hop, plus de souci de téléchargement à travers le WAN ! Merci qui ? Merci les Internets !

Attention : n’utilisez ce script QUE si vous avez des problèmes lorsqu’on vient télécharger depuis chez vous par exemple (téléversement, ou upload). Le patch en question concerne surtout OS X dans des conditions bien spécifiques. Ne l’appliquez pas « juste pour améliorer votre vitesse de téléchargement à Internet », ça ne servira sûrement à rien :-)

  1. Durant cette période de l’année où je suis particulièrement chargé, il m’a fallu presque cinq jours pour trouver la solution…
  2. Merci au support de Stella Telecom d’ailleurs, plutôt efficace.

Tester les périphériques réseau avec Safari et AppleScript

J’ai eu il y a quelques jours un souci qui arrive parfois à un administrateur réseau : impossible de retrouver un périphérique réseau (ici, un switch) via son adresse IP. En effet, l’appareil a été configuré en DHCP à l’origine, et personne n’avait modifié son adresse IP pour lui en attribuer une fixe… Du coup, pas forcément pratique à retrouver, sauf à installer un utilitaire sous Windows. Le moyen le plus simple était alors d’ouvrir l’interface web de configuration de l’appareil… mais tester 254 adresses IP ne me semblait pas la plus rapide des solutions. À moins d’automatiser le processus…

Attendez, vous avez dit automatiser ? Bon sur, mais c’est bien sang, AppleScript, à la rescousse ! J’ai donc concocté un petit script appelé sobrement Tester plage web avec Safari permettant d’ouvrir une page web pointant vers chaque adresse IP du sous-réseau local, l’une après l’autre, sur une plage de 256 adresses IP (correspondant à un masque de 255.255.255.0). Vous lancez le script, vous appuyez sur Exécuter, et un dialogue vous proposera de taper une adresse IP en utilisant par défaut votre plage d’adresse IP locale, puis de lancer la recherche. 

Tester IP

Pour le moment cette version ne teste que le port 80, mais je prévois une nouvelle version qui testera aussi en plus le port 443 (SSL) si vous le souhaitez.

Amusez-vous bien :-)

Télécharger le script (62 Ko)

Sous les (pa)VPN, la plage (IP)

C’est l’été, période propice aux tests… Alors voici un petit article technique, ça faisait longtemps hein ?

Depuis quelques années, les technologies VPN ont permis de faciliter l’accès à distance aux réseaux des entreprises. Petit rappel rapide de la technologie : en se connectant à l’aide d’un client VPN, un ordinateur situé à l’extérieur du réseau d’une entreprise établit un tunnel sécurisé vers un serveur VPN et ainsi se connecter au réseau de l’entreprise comme s’il s’agissait d’une connexion locale.

Dans l’absolu, cette technologie est géniale. Pour quelqu’un d’assez mobile comme moi, elle permet de me connecter aux ordinateurs des réseaux de mes clients pour corriger rapidement un dysfonctionnement ou mettre en place un service. Dans la pratique, elle est la plupart du temps aussi efficace qu’annoncée en théorie.

Il y a cependant un point parfois gênant. Quand vous configurez un routeur, il est par défaut configuré sur la plage 192.168.0.1/24 ou 192.168.1.1/24. Et on la laisse par défaut sur cette plage, sans se poser de questions. Et on monte donc son réseau sur cette plage, en se disant que ça va bien youpi. Et à mon goût, c’est une erreur.

En effet, lorsqu’un client VPN se connecte sur votre réseau, il va se voir attribué une adresse IP privée de votre plage distante. Mais que se passe-t-il si ce client est déjà connecté côté LAN sur un réseau utilisant la même plage que la plage distante ?

Voyez-vous où se trouve le problème ?

Cas concret : ma machine est sur un réseau en 192.168.1.1/24. Elle a l’adresse IP 192.168.1.2. Maintenant, je me connecte sur un réseau VPN dont la plage privée est également 192.168.1.1/24. Que se passe-t-il si, lors de la connexion distante, vous devez vous connecter vers un serveur en 192.168.1.100 ? Est-ce que votre client va devoir chercher cette adresse sur son réseau LAN, ou sur le réseau VPN ?

C’est là qu’il faut être futé. Car si on ne fait pas attention, boum, on se retrouve avec une connexion qui se fait, mais des postes distants inaccessibles. La meilleure solution est d’utiliser une plage réseau inutilisée d’habitude. Vous avez là l’embarras du choix, moi par exemple j’utilise une plage en 10.0.254.0/24 (et je vous interdis d’utiliser la même, non mais). Le tout est d’avoir une plage qui risque peu d’être utilisée en dehors de votre entreprise, 192.168.192.0, 10.0.77.0, 172.16.25.0… Vous choisissez. Mais PAS les plages par défaut !!!

Avec Mac OS X Server comme serveur VPN, il y a quelques astuces qui permettent cependant de limiter la casse sans changer tout le réseau. La première est d’ajouter dans les réglages du service VPN (avec Server Admin) la définition de votre réseau local. Ça permet au poste distant de mieux retrouver ses petits.

Ma plage est en 10.0.254.0, je l'ai donc définie comme plage privée dans mon VPN.

Une autre idée : dans les réglages du VPN côté client, vous pouvez forcer à envoyer tout le trafic réseau sur la connexion VPN distante. Attention : cela signifie que vos périphériques locaux ne fonctionneront plus…

En envoyant tout le trafic sur la connexion distante, vous augmentez les chances d'accéder à vos périphériques distants.

Voilà, vous savez tout. Mais vraiment, vraiment, si vous souhaitez limiter la casse, je vous invite à changer votre plage réseau si ce n’est pas déjà fait. Certes, cela demande une certaine planification pour les parcs importants, mais cela vous simplifiera certainement la vie dans le futur…

Comprendre et mettre en place Wide Area Bonjour

Yoann Gini a mis en ligne sur son blog quatre exceeeeeellents articles pour implémenter la technologie Wide Area Bonjour avec Mac OS X Server :

Wide Area Bonjour – Introduction et données statiques
Wide Area Bonjour – Une zone modifiable par tous
Wide Area Bonjour – Un peu plus loin dans l’enregistrement
Wide Area Bonjour – Authentification des clients par secret partagé

Et à quoi sert Wide Area Bonjour ? Principalement trois choses :
– Permettre de voir un périphérique sur le réseau dans une zone prédéfinie ;
– Rendre visible des services sur le réseau à l’aide du DNS, y compris à travers Internet ;
– Permettre à des périphériques du réseau d’ajouter leurs propres informations dans le service DNS Bonjour, fort utile là encore pour retrouver des périphériques à distance.

Une technologie magique, que Yoann a décortiqué avec talent, et vu le peu de docs, c’était pas gagné… Bravo à lui !