Reseau : dns

Bonsoir,

J’ai réinstallé mon serveur sur un nouveau hdd. J’ai un souci de dns visiblement car mon pc1 relié au serveur me renvoie un 400 bad request ! :12
Par exemple :

[quote]Err security.ubuntu.com precise-security/main Sources
400 Bad Request [IP : 91.189.88.149 80][/quote]

J’ai installé dnsmasq sur mon serveur-debian. Je ne comprends pas d’où vient l’erreur.

91.189.88.149 est bien une des adresses pointées par security.ubuntu.com.

Alors pourquoi j’obtiens cette réponse 400 bad request !

Sais pas. C’est Ubuntu. Connais pas.

Ça marchait avant (avant quoi) ?
En quoi le nouveau serveur intervient-il dans l’accès à security.ubuntu.com depuis PC1 ?

Non, pas possible, lorsque je retire la fiche rj45 du switch et que je la branche sur la livebox, je n’ai plus cette erreur.
Cela vient donc du serveur, non … ?
Ou je ne comprends plus rien !!

J’ai remis mon serveur-passerelle en route. J’ai simplement changé la carte wifi : une tp-link tl-wn951n.
Pour le reste, j’ai installé isc-dhcp-server + dnsmasq + squid3 + dansguardian. J’ai ensuite récupéré les fichiers de conf de l’ancien serveur sur hdd crashé dans le nouveau hdd.(cf post sur le disque hdd en rade).
Tous les clignotants sont au vert et pourtant : erreur dans un simple update.

depuis le serveur

[quote]cat /etc/resolv.conf
domain home
search home
nameserver 192.168.1.1
nameserver 192.168.1.1[/quote]

depuis un client

[quote]ubuntu:~$ cat /etc/resolv.conf

Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

DO NOT EDIT THIS FILE BY HAND – YOUR CHANGES WILL BE OVERWRITTEN

nameserver 81.253.149.9
nameserver 80.10.246.1
search monreseau[/quote]

[quote]ubuntu:~$ ping -n -c 4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

— 192.168.1.1 ping statistics —
4 packets transmitted, 0 received, 100% packet loss, time 2999ms[/quote]

[quote]ubuntu:~$ ip -4 neigh
172.16.10.1 dev eth0 lladdr 00:08:a1:6d:be:ef REACHABLE
tristan@tristan-ubuntu:~$ cat /etc/resolv.conf

Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

DO NOT EDIT THIS FILE BY HAND – YOUR CHANGES WILL BE OVERWRITTEN

nameserver 81.253.149.9
nameserver 80.10.246.1
search monreseau[/quote]

J’ai déjà eu ce problème mais la réponse ne résout pas le problème :

Un problème dans le noyau ?

[quote]uname -r
3.2.0-4-686-pae[/quote]

[quote]grep NF_NAT /boot/config-$(uname -r)
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_NF_NAT_PROTO_DCCP=m
CONFIG_NF_NAT_PROTO_GRE=m
CONFIG_NF_NAT_PROTO_UDPLITE=m
CONFIG_NF_NAT_PROTO_SCTP=m
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_TFTP=m
CONFIG_NF_NAT_AMANDA=m
CONFIG_NF_NAT_PPTP=m
CONFIG_NF_NAT_H323=m
CONFIG_NF_NAT_SIP=m[/quote]

[quote]# find /lib/modules/uname -r/kernel/net/ipv4/netfilter
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_conntrack_ipv4.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_nat_proto_sctp.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/ipt_NETMAP.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/ipt_LOG.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/ip_tables.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_nat_tftp.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_nat_pptp.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/ipt_REJECT.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_nat_snmp_basic.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/ipt_ah.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/ipt_ecn.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/iptable_nat.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/arpt_mangle.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/ipt_ULOG.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_nat_irc.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/iptable_filter.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/iptable_security.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/ip_queue.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_nat_sip.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_nat_h323.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_nat_proto_udplite.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_defrag_ipv4.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/ipt_CLUSTERIP.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/iptable_mangle.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/arp_tables.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_nat.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_nat_proto_dccp.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_nat_ftp.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_nat_proto_gre.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/iptable_raw.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/nf_nat_amanda.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/arptable_filter.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/ipt_REDIRECT.ko
/lib/modules/3.2.0-4-686-pae/kernel/net/ipv4/netfilter/ipt_ECN.ko[/quote]

Tout à l’air ok pourtant.

Je ne comprends pas ou je ne vois pas :open_mouth:

Proxy transparent ?

Non normalement : il est configuré sur le navigateur. Je vérifie.

root@serveur-debian:/etc/iptables# nano rules.v4

[code]# Generated by iptables-save v1.4.14 on Tue Jan 27 15:14:04 2015
*filter
:INPUT ACCEPT [153075:131152433]
:FORWARD ACCEPT [733:125748]
:OUTPUT ACCEPT [145884:132612179]
COMMIT

Completed on Tue Jan 27 15:14:04 2015

Generated by iptables-save v1.4.14 on Tue Jan 27 15:14:04 2015

*nat
:PREROUTING ACCEPT [19:1359]
:INPUT ACCEPT [1:60]
:OUTPUT ACCEPT [1:60]
:POSTROUTING ACCEPT [2:303]
-A PREROUTING -i br0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT[/code]

Cela n’a pas d’importance mais si le proxy était configuré explicitement sur le poste, cela ne fonctionnerait pas lorsqu’il est connecté directement à la box. En tout cas ton serveur a bien un règle iptables d’interception du port 80 vers le port local 3128, qui correspond à un proxy. Transparent ou pas, je soupçonne que c’est le proxy (squid+dansguardian) qui te renvoie cette erreur 400.

Tu as cette erreur avec tous les sites web ou seulement avec ce serveur d’Ubuntu ?

Ah ben mince alors ! je fais comment ? Tu as une idée ?

Qarte+ me renvoie une erreur mais pas lequipe par exemple.

Reason: <urlopen error [Errno -2] Nom ou service inconnu>

Vérifie la configuration du proxy et ses logs d’erreur.

J’ai configure,via synaptic,le gestionnaire de mises à jour pour l’utilisation du proxy et çà marche.
Par contre , via la konsole, çà marche pas !!

Trouvé :stuck_out_tongue:

1/ Modifier le fichier wgetrc : # nano /etc/wgetrc.conf

[code]# You can set the default proxies for Wget to use for http, https, and ftp.

They will override the value in the environment.

#https_proxy = http://proxy.yoyodyne.com:18023/
#http_proxy = http://proxy.yoyodyne.com:18023/
#ftp_proxy = http://proxy.yoyodyne.com:18023/
http_proxy = http://toto69:motdepasse@172.16.10.1:3128/
ftp_proxy = http://toto69:motdepasse@172.16.10.1:3128/[/code]

2/Modifier ou créer le fichier apt.conf dans /etc/apt ; puis ajouter cette ligne:

Faire ensuite un # apt-get update

Tu as mis un mot de passe à ton proxy et tu veux l’utiliser en proxy transparent (cf. règle iptables d’interception et redirection du port 80) ???

Je ne comprends pas ce que tu me dis !

D’une part, le jeu de règles iptables contient une règle NAT qui intercepte les connexions HTTP (port 80/TCP) provenant du LAN et les redirige vers le port 3128 local sur lequel écoute le proxy. J’en déduis que c’est pour mettre en place un proxy transparent, sans que les postes du LAN aient besoin d’être configurés explicitement.

D’autre part, l’URL du proxy définie dans la variable d’environnement http_proxy contient une authentification avec identifiant (toto69) et mot de passe (motdepasse). J’en déduis que le proxy exige une authentification pour relayer les requêtes HTTP.

Or par définition un proxy transparent ne peut pas exiger une authentification de la part du client puisque celui-ci ne sait même pas qu’il passe par un proxy ! Cela ne peut pas marcher, et je soupçonne que c’est la cause de l’erreur que tu as rapportée dans ton message initial.

Est-ce clair ?