Lenteurs DNS et HTTP chez Free

Résolution DNS

J'utilise désormais un serveur DNS différent de ceux fournis par Free, tout en continuant à utiliser le service DHCP fourni par la Freebox.

Pour ce faire, sous Debian 5.0, il est nécessaire de configurer le client DHCP pour ne pas que les serveurs DNS annoncés en DHCP écrasent les valeurs manuelles que l'on spécifie.

Il suffit pour cela d'ajouter la ligne suivante au fichier /etc/dhclient/dhclient.conf, afin de spécifier ses propres valeurs pour les lignes nameserver du fichier /etc/resolv.conf :

supersede domain-name-servers 8.8.8.8, 8.8.4.4;

(attention au point-virgule final)

On utilise dans cet exemple les serveurs DNS ouverts de Google, pour ma part j'utilise mon propre serveur DNS hébergé sur un serveur externe. Enfin, il suffit de relancer le client DHCP avec une commande de ce type :

pkill dhclient && dhclient eth0

Pour finir, vérifier que le contenu du fichier /etc/resolv.conf correspond bien à celui attendu, et constater avec plaisir une amélioration de la vitesse de ses requêtes DNS.

HTTP

J'utilise un proxy SOCKS, qui tourne sur un serveur externe au réseau Free.

Cela permet de contourner le bridage qui impacte les connexions directes entre Free et certains opérateurs.

Pour cela, j'utilise le serveur SOCKS Dante sous FreeBSD, avec un fichier de configuration de ce type :

# This value controls where the server sends logoutput.  It can be
# either  syslog[/facility], stdout, stderr, a filename, or a com-
# bination.
logoutput: /var/log/sockd.log

# The  internal  addresses.   Connections will only be accepted on
# these addresses.  The address given may be either a  IP  address
# or a interfacename.
internal: 192.0.2.1 port = 31281

# The address to be used for outgoing  connections.   The  address
# given  may  be  either  a IP address or a interfacename.  Can be
# given multiple times for different addresses.
external: 192.0.2.1

# Allow connections without authentication
method: none

# when doing something that can require privilege, it will use the
# userid "sockd".
user.privileged: sockd

# when running as usual, it will use the unprivileged userid of "sockd".
user.notprivileged: sockd

# If you compiled with libwrap support, what userid should it use
# when executing your libwrap commands?  "libwrap".
user.libwrap: sockd

# In the client-rule  context,  to  means  the  address  the  request  is
# accepted on, i.e. the address the Dante server listens on.
client pass {
    from: 192.51.100.1/32 to: 192.0.2.1/32
    log: connect error
}

# In  the  socks-rule context, to means the client's destination address,
# as formulated in the client's proxy request.
pass {
    from: 192.51.100.1/32 to: 0.0.0.0/0
    protocol: tcp
    log: connect error
}

En résumé, cette configuration autorise l'accès au serveur SOCKS à partir de mon adresse IP (192.51.100.1), vers n'importe quelle destination en TCP (0.0.0.0/0).

Le serveur SOCKS écoute sur le port 31281 de la machine 192.0.2.1, et utilise également l'adresse IP 192.0.2.1 pour ses connexions sortantes. Une fois le serveur sockd fonctionnel et en écoute sur le port choisi, il suffit de configurer son navigateur pour l'utiliser (c'est notamment possible avec Firefox).

Pour finir, il ne reste plus qu'à contempler la barre de chargement de ses vidéos favorites progresser plus vite que la progression de la vidéo !