J'ai récemment passé mon serveur de fichiers (FTP et Samba) maison en IP statique. Ce faisant, j'ai noté une réactivité beaucoup plus faible du serveur.
En DHCP :
ssh 192.168.1.66le prompt "password" apparait une à deux secondes après la demande d'ouverture de connexion.
En statique :
ssh 192.168.1.10le prompt alors prend une petite dizaine de secondes.
Ce n'est pas grave en soit, mais ca fait quand même long, pour un réseau local...
La où ca devient plus agaçant, c'est pour les connexions FTP, qui ont comme un arriere-gout de 56K... Les temps de transferts sont satisfaisants... une fois que le transfert a daigné démarrer ! Cela rend la navigation dans l'arborescence un peu laborieuse.
Je parle de la réactivité du serveur, càd du temps qu'il met à répondre à une requête (connexion SSH, ouverture d'un répertoire FTP...), car les temps sont identiques (ping révèle des taux moyens équivalents).
Mes pistes de recherche :
1/ Une adresse IP inadaptée. J'ai testé égalementavec 192.168.1.20 (comme le routeur s'arroge 192.168.1.1, j'ai songé -naïvement ?- a un conflit avec 192.168.1.10), et le routeur annonce que la table DHCP commence à 192.168.1.64 (Start IP address)
2/ Un /etc/network/interfaces mal tourné :
22:46 root@bigbox ~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.20
netmask 255.255.255.0
#auto eth1
#iface eth1 inet static
# address 192.168.1.11
# netmask 255.255.255.03/ Le masque de sous-réseau. 255.255.255.0, mais je m'interroge surtout parce que j'ignore son utilité...
4/ La seconde carte NIC que j'ai récemment ajoutée afin de construire un bridge ultérieurement. Elle est correctement reconnue par lspci (ça ne prouve rien), j'ai recompilé un noyau incluant son pilote, et j'ai pris soin de bien commenter toute la partie relative à eth1 dans /etc/network/interfaces
5/ Je suspecte aussi (et avant tout...) mon routeur. C'est un Linksys WAG354G avec le dernier firmware officiel disponible (je ne me sens pas trop de le charger avec un firmware experimental). Se pourrait-il que celui-ci prenne son temps, lorsqu'il s'agit de connecté un poste en IP statique, plutôt au'en DHCP ?
Merci de votre aide, toute suggestion de recherche pour parvenir à résoudre ce problème est la bienvenue et toute solution l'est également ;)
Erwann
Mon LSPCI (eth0 est l'interface SiS900):
22:46 root@bigbox ~# lspci
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 760/M760 Host (rev 03)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SG86C202
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO] (rev 36)
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev 01)
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 91)
00:05.0 IDE interface: Silicon Integrated Systems [SiS] RAID bus controller 180 SATA/PATA [SiS] (rev 01)
00:07.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760/761 PCI/AGP VGA Display Adapter
22:46 root@bigbox ~#
# Résolutions DNS
Posté par Raphaël SurcouF (site web personnel) . Évalué à 7.
Les temps de latence à la connexion sont typiquement dûs à une résolution DNS inverse de la part du serveur SSH.
[^] # Re: Résolutions DNS
Posté par NeoX . Évalué à 4.
/etc/resolv.conf -> pour la resolution DNS car en dhcp il est rempli par le dhcp
/etc/hosts -> pour la resolution local (si y a pas de DNS)
et dans /etc/hostname il faut que le nom soit le meme que dans le /etc/hosts
et si tu utilise un DNS interne, il faut verifier qu'il renvoie le bon couple IP/NOM
[^] # Re: Résolutions DNS
Posté par error404 . Évalué à 1.
En effet, mon /etc/resolv.conf n'est pas configuré. Comme il s'agit d'un serveur de fichiers sans GUI, caché dans un placard sans écran ni clavier, géré uniquement en SSH, j'étais sur le point de dire que cela n'a pas d'importance... sauf qu'apt-get fait la tronche, maintenant, pour se connecter sur ftp.fr.debian.org...
Il semble que les DNS de mon FAI ont été copiés automatiquement. En revanche, apt-get ne se déride pas, quel "search domain" dois-je mettre ?
De plus, cela peut-il réellement expliquer les temps de latence lors d'une connection SSH ou FTP depuis mon ordinateur portable ? En effet, si j'ai bien compris ce qu'est un DNS, il n'est pas utilisé lors de la commande...
...puisque je renseigne directement l'adresse IP locale de mon serveur.
Pourtant, la connection demande de la patience avant de s'établir...
[^] # Re: Résolutions DNS
Posté par symoon . Évalué à 7.
La directive "search domain.tld" permet d'indiquer juste toto quand tu veux aller sur toto.domain.tld, c'est juste un raccourci.
Pour le coup, c'est encore un problème de DNS, mais côté serveur cette fois-ci. En effet, celui-ci essaie d'effectuer la résolution inverse de ton ip, afin d'afficher un nom (titi.domain.tld) au lieu de l'ip dans les logs (que cela soit ssh, ftp, apache, etc.).
Dans la conf de sshd :
[^] # Re: Résolutions DNS
Posté par error404 . Évalué à 1.
Je comprends un peu mieux l'importance de resolv.conf maintenant que j'ai passé mon serveur en IP statique. En revanche, je ne saisis pas quel nom de domaine renseigner en face de "search".
J'ai tenté le coup avec les domaines suivants, sans résultat :
Ce que je ne saisis pas, quand je lis que je dois mettre "mon" domaine, c'est que je n'en possède pas.
Il s'agit d'un simple réseau local, avec une connexion ADSL/IP fixe, et je n'héberge ni ne maintiens aucun site web. Je souhaite juste pouvoir accéder à mes fichiers par FTP en local en donnant le nom de mon serveur, et depuis l'extérieur en tapant l'IP que m'a fourni mon FAI.
Merci de votre aide, j'ai rarement obtenu autant de réponses pertinentes et utiles sur un forum en aussi peu de temps,
Erwann
[^] # Re: Résolutions DNS
Posté par symoon . Évalué à 5.
Dans ce cas, n'utilise pas cette directive, donc pas de ligne search :-)
Autre chose : vérifier sur l'adresse IP configurée en statique colle avec celle que tu as indiqué dans le /etc/hosts.
[^] # Re: Résolutions DNS
Posté par error404 . Évalué à 1.
Symoon, ton explication pourrait en effet expliquer le temps de latence du serveur, mais :
1/Pourquoi la connection finit-elle par s'établir ? Cela signifie-t-il que le serveur, après avoir tenté d'obtenir le nom du client pour mettre dans ses logs, accepte en définitive la connection (dans ce cas, le log n'a qu'une utilité relative, d'un point de vue sécurité...) ?
2/ Mon portable est connecté sans fil, d'où l'usage du DHCP, alors que mon serveur est en Ethernet. Comment rendre possible la résolution du nom du client (mon portable), sinon en mettant à jour /etc/hosts chaque fois que le bail DHCP du portable change ? En effet, si le serveur DHCP (mon routeur) gère toutes les résolutions de noms, alors cela pourrait expliquer pourquoi la connection est plus réactive quand les deux ordinateurs (serveur et client) sont en DHCP.
Sinon, mes recherches continuent, et je suis en train de lire des trucs sur le paquet resolvconf, qui n'est pas installé sur mon serveur. Est-il nécessaire que je l'installe ?
Merci,
Erwann
[^] # Re: Résolutions DNS
Posté par NeoX . Évalué à 3.
cela permettrait de laisser tout le monde en DHCP et de dire que la carte reseau (via l'adresse MAC) de ton serveur, obtient toujours la meme adresse IP.
[^] # Re: Résolutions DNS
Posté par error404 . Évalué à 1.
Malheureusement non, mon ancien routeur SMC permettait cette configuration, mais sur ce Linksys, les baux DHCP durent au maximum un jour.
[^] # Re: Résolutions DNS
Posté par symoon . Évalué à 2.
Timeout au niveau de la résolution DNS.
La vérification faite au niveau DNS n'apporte pas grand chose niveau sécurité: la connexion sera refusée si jamais l'ipB résolue depuis le nom lui-même résolu inverse de l'ipA (qui initie la connexion) est différente de ipA.
Les logs ne sont pas pour autant moins utiles si seule l'IP est inscrite.
L'adressage DHCP/statique n'a rien à voir avec le medium filaire ou pas.
Regarde quel serveur DNS te renvoie le serveur DHCP, a priori 192.168.1.1 comme vu plus haut, donc tu peux sur tes machines indiqeur ce serveur DNS comme 1er serveur utilisé (et non pas 3eme).
[^] # Re: Résolutions DNS
Posté par error404 . Évalué à 1.
Euh... volontiers, mais je vois ça comment ?
Voici mon /etc/resolv.conf en l'état (en 2e et 3e DNS, j'ai inséré ceux donnés par mon FAI sur leur courrier papier, dont un qui est différent de ceux, commentés, utilisés par mon routeur)
Et mon /etc/hosts :
Je n'ai donc pas inséré l'adresse de mon portable, puisqu'en DHCP.
En revanche, y aurait-il qqchose à gagner à mettre l'adresse de mon routeur ? Je dois m'absenter, mais je tenterai ce soir.
Erwann
[^] # Re: Résolutions DNS
Posté par Olivier Jeannet . Évalué à 2.
J'ai aussi configuré le serveur DHCP de mon modem/routeur pour qu'il m'attribue toujours la même IP, en restreignant la plage à une seule adresse (192.168.1.2 tout simplement).
[^] # On avance, on avance...
Posté par error404 . Évalué à 1.
Pour retrouver un password prompt SSH qui ne prend plus 15 secondes avant de pointer son nez, j'ai modifier mon /etc/resolv.conf comme suit :
L'astuce consiste à mettre comme premier nameserver non pas l'IP de mon routeur 192.168.1.1 mais l'adresse qui correspond à la Destination LAN IP de l'interface "LAN & Wireless" de la table de routage du Linksys (Setup>Advanced Routing>Show Routing Table), càd 192.168.1.0
On retrouve alors également un temps d'établissement de la connection FTP réduit, une navigation dans l'arborescence FTP plus fluide et des transferts qui ne mettent plus une plombe à démarrer.
Olivier, merci pour ton astuce :C'est une idée, mais malheureusement, plusieurs portables se connectent, car je vis en colloc, et les potes de passage sont également friands de la connection internet...
C'est donc un progrès. Reste néanmoins un problème, de taille:
apt-get ne parvient toujours pas à établir de connection vers les miroirs Debian, pas plus que ping ne peut "pinger".
Encore du boulot donc... mais pas pour ce soir.
Bonne nuit à tous,
[^] # Re: On avance, on avance...
Posté par benoar . Évalué à 2.
Le truc qu'il nous manque c'est de savoir comment est ta config réseau : c'est très illogique d'avoir ton propre serveur et les DNS de ton FAI dans ton resolv.conf. Tu parles bien du /etc/resolv.conf de ton routeur là, oui ? Alors tu mets juste les DNS de ton FAI. C'est dans le resolv.conf de ton client que tu mettra l'adresse de ton routeur comme DNS, mais seulement s'il fait relai DNS. Mais de toutes façons, cela devrait être fait automatiquement par DHCP.
[^] # Re: On avance, on avance...
Posté par Olivier Jeannet . Évalué à 1.
Et surtout, soit tu mets l'adresse des DNS de ton FAI (ici tu as mis 2 fois la même, ce qui ne sert à rien), soit tu mets l'adresse de ton modem-routeur (s'il fait relais DNS). Comme je te le disais, normalement tu n'as rien à faire, le client DHCP de ton Linux va s'occuper de le faire (cela fait plusieurs distributions que je n'ai rien à faire côté Linux, juste à dire de se connecter via DHCP).
Pour revenir à ce que tu disais dans ta question initiale, si tu choisis d'utiliser une IP fixe, il faut alors que tu précises une adresse de serveur DNS dans /etc/resolv.conf (que ce soit l'adresse du modem-routeur s'il fait relais DHCP, ou l'adresse du DNS de ton FAI), vu que le client DHCP ne sera pas là pour s'en occuper.
Je me connecte sur mon serveur SSH ou SFTP (qui est chez moi) depuis le boulot, et je n'ai aucun délai. Ah oui, tu devrais pouvoir désactiver la résolution de nom de ton serveur FTP ou SSH (pour ma part je le laisse activé), auquel cas peu importe qu'un DNS soit spécifié ou accessible.
[^] # Re: On avance, on avance...
Posté par error404 . Évalué à 1.
Mon réseau est assez simple. Un modem/routeur Linksys qui entretient la connection internet, et auquel sont connectés :
1/ Plusieurs portables, en Wi-Fi, obtenant leur IP par le DHCP du routeur
2/ Un serveur (FTP, Samba et SSH), dans un placard, connecté en Ethernet, pour lequel je souhaite une IP fixe, afin de pouvoir accéder à mes docs en FTP depuis l'extérieur, sans avoir à reconfigurer régulièrement la table de routage du routeur au fur et à mesure que les baux DHCP expirent.
Voilà pour les forces en présence.
Maintenant, je pense que la situation est en réalité assez simple, et le /etc/resolv.conf suivant devrait suffire, au moins en théorie (seules les dernières lignes sont utiles):
Mon erreur aura été de laisser "search" au départ, puis de retirer cette option ET d'insérer l'adresse de mon routeur 192.168.1.1, ce qui a peut-êtrecourt-circuité l'usage des DNS de mon FAI, et rendu l'IP lookup du serveur plus lente lors des requêtes SSH et FTP, car je doute que le routeur fasse serveur DNS. En changeant 192.168.1.1 en 192.168.1.0 j'ai p-e indiqué une adresse inexistante, ce qui a amené le serveur à utiliser le DNS du FAI (?).
Ne conserver que les deux dernières lignes résoud le problème de réactivité (ou les deux du milieu qui, malgré les apparences, sont bien différentes;-] ).
J'ai certainement complexifié un peu la situation au départ (mais bon, je débute et je tatonne), comme bien souvent sous Linux, la configuration est bien plus simple que ce à quoi on est habitué sous d'autres systèmes, une ligne dans un fichier au bon endroit suffit...
Maintenant que mon serveur fait appel à des serveurs DNS valides, il devrait être content.
Et pourtant...
ping ne ping pas
apt-get update me gratifie du message suivant :
Une idée sur ce que j'ai encore pu faire de travers ?
Merci pour votre aide,
[^] # Re: Résolutions DNS
Posté par error404 . Évalué à 1.
Tout semble-t-il normal ? Je me pose cette question car la même commande depuis mon portable en DHCP retourne :
Ok, ce n'est pas super lisible, mais l'absence d'une ligne "default" dans la table de mon serveur pourrait-elle expliquer pourquoi j'obtiens des "Network unreachable" avec ping, apt-get, etc. ?
Si oui, comment rajouter cette ligne (route add qqchose, j'imagine) ?
Merci,
[^] # Re: Résolutions DNS
Posté par NeoX . Évalué à 1.
et si ca marche, pour que cela fonctionne à chaque demarrage, il y a 2 fichiers à modifier pour faire une config IP statique
/etc/resolv.conf
pour mettre les bons DNS
/etc/network/interfaces (sur une debian like)
pour mettre l'IP et le masque, le routeur
man interfaces
nous dis
[^] # Résolu !
Posté par error404 . Évalué à 1.
Ne sachant pas ce qu'était le gateway, je l'avais commenté dans /etc/resolv.conf
Rajouter l'adresse de mon routeur a de nouveau permis l'accès à l'extérieur pour mon serveur. apt-get est actuellement en train de faire des mises à jour :)
Cela explique pourquoi je pouvais pinger seulement les machines du réseau local.
Il ne s'est pas révélé nécessaire d'utiliser la commande route.
Un grand merci à tous pour votre patience avec un newbie complet des réseaux !
[^] # Re: Résolu !
Posté par NeoX . Évalué à 1.
la commande route permet de changer/rajouter/enlever des gateway.
sans pour autant memoriser le reglage dans la config (utile pour les tests)
[^] # Re: Résolu !
Posté par error404 . Évalué à 1.
Prochaines etapes : montage sur le client d'un volume NFS du serveur (donc installation du serveur ad hoc), puis mise en place d'un bridge entre le serveur et le client pour qu'ils dialoguent enfin a 1GBit, sans passer par le routeur...
A tres bientot sans aucun doute, dans un sujet approprie ! :)
# Même problème
Posté par Toto . Évalué à 1.
Je profite de ce post pour signaler que j'ai quasiment le même problème sur ma debian unstable (en DHCP ou en statique). Je n'ai pas encore eu le temps d'investiguer, mais voici mes symptomes :
- lenteur d'établissement de la connexion, puis débit OK
- les pings sont etrangement long, même en spécifiant l'option de flood.
Voici par exemple ce que j'observe sur ma machine lorsque je fais un ping sur ma passerelle :
- lancement de la commande ping
- 3 secondes plus tard paquet de résolution ARP, réponse immédiate
- 3 secondes plus tard emission d'un ICMP echo, reception d'un ICMP reply immédiate
- 3 secondes plus tard emission d'un ICMP echo, reception d'un ICMP reply immédiate
Inversement quand je ping cette machine, j'ai un délai de 2-3seconde entre la requete ARP / ICMP echo et la réponse ARP / ICMP reply.
J'ai pensé à un driver buggé, mais ca me le fait sur mon Wifi et sur mon filiaire. J'ai désactivé tous mes firewalls, mis une table de routage statique avec en /24 ou 32..
Merci pour toute aide
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.