Whois: getaddrinfo(whois.nic.or.kr): Nom ou service inconnu

@syam

Énorme cette put***, de poutre … :005 Merci … :wink:

Package: * Pin: release o=Debian,a=stable-updates,l=Debian Pin-Priority: 990

Et cela m’apprendra à faire des copier/coller sans chercher à comprendre … :075 :mrgreen:

:~$ acp libc6 libc6: Installé : 2.11.3-2 Candidat : 2.11.3-3 Table de version : 2.13-26 0 90 http://ftp.fr.debian.org/debian/ wheezy/main amd64 Packages 50 http://ftp.fr.debian.org/debian/ sid/main amd64 Packages 2.11.3-3 0 990 http://ftp.fr.debian.org/debian/ squeeze-updates/main amd64 Packages *** 2.11.3-2 0 990 http://ftp.fr.debian.org/debian/ squeeze/main amd64 Packages 100 /var/lib/dpkg/status :~$

:~# aptitude -s upgrade Les paquets suivants seront mis à jour : libc-bin libc-dev-bin libc6 libc6-dev libc6-i386 locales Les paquets suivants sont RECOMMANDÉS mais ne seront pas installés : manpages-dev 6 paquets mis à jour, 0 nouvellement installés, 0 à enlever et 1 non mis à jour. Il est nécessaire de télécharger 16,4 Mo d'archives. Après dépaquetage, 705 ko seront utilisés. Voulez-vous continuer ? [Y/n/?] y Charger/installer/enlever des paquets. :~#

yapuka … :033

Il me semble (à confirmé dans les prochains jours) qu’icedove à repris du poil de la bête. :023

Sinon …

:~$ acp libc6 libc6: Installé : 2.11.3-3 Candidat : 2.11.3-3 Table de version : 2.13-26 0 90 http://ftp.fr.debian.org/debian/ wheezy/main amd64 Packages 50 http://ftp.fr.debian.org/debian/ sid/main amd64 Packages *** 2.11.3-3 0 990 http://ftp.fr.debian.org/debian/ squeeze-updates/main amd64 Packages 100 /var/lib/dpkg/status 2.11.3-2 0 990 http://ftp.fr.debian.org/debian/ squeeze/main amd64 Packages :~$

Malheureusement … :think:

:~$ whois www.google.com connect: Connexion terminée par expiration du délai d'attente :~$

Au moins le message d’erreur a changé, il ne fait plus référence à un problème de résolution de nom. Tu peux refaire un strace ou une capture du trafic ?

Bien sur … :wink:

[code]:~$ strace whois www.google.com 2>&1 | grep -E ‘connect|sendto|recvfrom’ | grep -E ‘whois|53’

:~$
[/code]

[code]:~# tcpdump -nS

:~#
[/code]

[code]:~# tcpdump -nnvvS

:~#
[/code]

[code]:~# tcpdump

:~#
[/code]

Bon moi les captures réseau ça me cause pas du tout (faudra que j’apprenne à décoder ça un jour) par contre le strace ça serait mieux en entier, pour voir quel appel précis coince. :wink:
Enfin déjà comme ça on voit qu’il ne folèye plus comme avant au niveau DNS, mais ça ne fait que confirmer la remarque de Pascal.

[quote=“syam”]Bon moi les captures réseau ça me cause pas du tout (faudra que j’apprenne à décoder ça un jour) par contre le strace ça serait mieux en entier, pour voir quel appel précis coince. :wink:
Enfin déjà comme ça on voit qu’il ne folèye plus comme avant au niveau DNS, mais ça ne fait que confirmer la remarque de Pascal.[/quote]

huumm, dans les deux cas, pour moi c’est encore du chinois … :shhh: :119

[code]:~$ strace whois www.google.com

:~$
[/code]

socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(43), sin_addr=inet_addr("199.7.59.74")}, 16) = -1 ETIMEDOUT (Connection timed out)
Tu as toujours le port TCP 43 autorisé en OUTPUT dans ton iptables ?

# iptables -S | grep ' 43 '

Bon et après faudra s’occuper de ton firewall hein… :mrgreen:

Tout à fait.

:~# iptables -S | grep ' 43 ' -A OUTPUT -p tcp -m tcp --dport 43 -j ACCEPT -A OUTPUT -p udp -m udp --dport 43 -j ACCEPT :~#

[quote=“syam”]

Bon et après faudra s’occuper de ton firewall hein… :mrgreen:[/quote]

Tu crois … :005 un coup de pouce sera le bienvenu … :wink:

En effet on voit bien la différence dans strace et la capture : les deux requêtes DNS A et AAAA sont émises séquentiellement et non plus simultanément. Ainsi les réponses arrivent dans l’ordre et le resolver n’est plus perturbé par l’erreur en réponse à la requête AAAA.

15:04:43.097147 IP 192.168.1.12.34981 > 192.168.1.1.53: 19890+ A? whois.crsnic.net. (34) 15:04:43.297899 IP 192.168.1.1.53 > 192.168.1.12.34981: 19890 1/0/0 A 199.7.59.74 (50) 15:04:43.298086 IP 192.168.1.12.34981 > 192.168.1.1.53: 47165+ AAAA? whois.crsnic.net. (34) 15:04:43.299707 IP 192.168.1.1.53 > 192.168.1.12.34981: 47165 NotImp- 0/0/0 (34)

C’est assez facile à lire quand on est familiarisé avec les protocoles IP mis en oeuvre. Mais il faut apprendre chaque protocole (IP, ARP, TCP, UDP, ICMP…).

C’est vrai, mais en fait la capture réseau le rend inutile :

15:04:43.299874 IP 192.168.1.12.56682 > 199.7.59.74.43: Flags [S], seq 839850314, win 5840, options [mss 1460,sackOK,TS val 343688823 ecr 0,nop,wscale 6], length 0 15:04:46.298512 IP 192.168.1.12.56682 > 199.7.59.74.43: Flags [S], seq 839850314, win 5840, options [mss 1460,sackOK,TS val 343689573 ecr 0,nop,wscale 6], length 0 15:04:52.298496 IP 192.168.1.12.56682 > 199.7.59.74.43: Flags [S], seq 839850314, win 5840, options [mss 1460,sackOK,TS val 343691073 ecr 0,nop,wscale 6], length 0
Juste après les communications DNS, on voit sortir trois demandes de connexion TCP (SYN) successives vers le port 43 (whois) de l’adresse IPv4 renvoyée dans la réponse DNS. Mais pas de réponse en retour, d’où le message d’erreur de whois “expiration du délai d’attente”.

A priori oui, sinon les paquets SYN sortants n’arriveraient pas jusqu’à l’interface et ne seraient pas vus par tcpdump. De même j’exclus a priori un éventuel filtrage des réponses SYN/ACK par iptables car même dans ce cas tcpdump devrait les voir arriver.

Note : que donnent des requêtes whois sur d’autres domaines, sur des adresses IP ?

La suite …

:~$ whois www.debian-fr.org

[code]:~# tcpdump -nS

:~#[/code]

:~$ whois www.isalo.org

[code]:~# tcpdump -nS

:~# [/code]

Ici deux vilains, bannies par fail2ban. :033

:~$ whois 213.128.82.133

[code]:~# tcpdump -nS

:~# [/code]

:~$ whois 213.128.75.196

[code]:~# tcpdump -nS

:~# [/code]

Une idée qui peut aider à déterminer où ça coince : lancer un traceroute en TCP (installer un des paquets qui le fournissent si pas disponible, par exemple traceroute ou tcptraceroute) sur le port 43 vers l’adresse qui ne répond pas.

Attention whois.crsnic.net a plusieurs adresses, l’adresse retournée par le DNS peut changer à chaque fois.

[Edit] (nos messages se sont croisés) - Bon si ça fait pareil avec tous les serveurs whois, le blocage n’est probablement pas du côté du serveur…

[code]:~# tcptraceroute whois.crsnic.net 43

Selected device eth0, address 192.168.1.12, port 42167 for outgoing packets
Tracing the path to whois.crsnic.net (199.7.52.74) on TCP port 43 (whois), 30 hops max
1 192.168.1.1 0.819 ms 0.497 ms 0.484 ms
2 * * *
3 * * *

30 * * *
Destination not reached
:~#
[/code]

:~# traceroute whois.crsnic.net 43 traceroute to whois.crsnic.net (199.7.59.74), 30 hops max, 43 byte packets send: Opération non permise :~#

[quote=“PascalHambourg”]

Bon si ça fait pareil avec tous les serveurs whois, le blocage n’est probablement pas du côté du serveur…[/quote]

Que dois je comprendre par là Pascal … iptables ?

Et si tu désactives complètement ton firewall juste pour tester ? Vu que tu es derrière une Livebox, ça ne risque rien le temps de faire le test…

iptables -P INPUT ACCEPT iptables -F INPUT iptables -P OUTPUT ACCEPT iptables -F OUTPUT whois google.com

Rien à voir avec ton problème, mais comme je viens de remarquer ça j’en profite pour te donner l’info : le whois se fait sur le nom de domaine (domaine.tld) pas sur le nom d’hôte (hote.domaine.tld).

$ whois www.debian-fr.org NOT FOUND $ whois debian-fr.org [... toutes les infos ...]
Le pire c’est que dans tout le fil j’ai fait comme toi. :smiley:

Tu vois, t’es pas tout seul ! :eusa-whistle:

J’ai intégré ceci au firewall … :017

[code]# Interdit toute connexion entrante ou sortante
#iptables -P INPUT DROP
#iptables -P FORWARD DROP
#iptables -P OUTPUT DROP
#echo “- Interdire toute connexion entrante ou sortante : [OK]”

iptables -P INPUT ACCEPT
iptables -F INPUT
iptables -P OUTPUT ACCEPT
iptables -F OUTPUT
echo “- Autoriser Temporairement toute connexion entrante ou sortante : [OK]”
[/code]

/etc/init.d/firewall restart

:~$ whois debian-fr.org connect: Connexion terminée par expiration du délai d'attente :~$

:~# whois debian-fr.org connect: Connexion terminée par expiration du délai d'attente :~#
Plaisant comme situation … :mrgreen:

Rhoooo toi alors, :016 une chance que je n’ai pas laissé traîner une corde le long de ce fil … :005 :005 :005

[quote=“loreleil”]J’ai intégré ceci au firewall … :017

[code]# Interdit toute connexion entrante ou sortante
#iptables -P INPUT DROP
#iptables -P FORWARD DROP
#iptables -P OUTPUT DROP
#echo “- Interdire toute connexion entrante ou sortante : [OK]”

iptables -P INPUT ACCEPT
iptables -F INPUT
iptables -P OUTPUT ACCEPT
iptables -F OUTPUT
echo “- Autoriser Temporairement toute connexion entrante ou sortante : [OK]”
[/code]

/etc/init.d/firewall restart

Mais bien entendu tu as fait un exit immédiatement après, ou bien tu as commenté toutes tes règles bizarres ? :mrgreen:

Le but c’est d’obtenir un firewall totalement vierge :

# iptables -S -P INPUT ACCEPT -P FORWARD DROP -P OUTPUT ACCEPT

Edit : je viens de tester sur une bécane que je sais être derrière une Livebox, le whois marche (mais je n’en doutais pas). C’est donc bien sur ta machine que le problème se trouve.

[quote=“syam”][quote=“loreleil”]J’ai intégré ceci au firewall … :017

/etc/init.d/firewall restart

Mais bien entendu tu as fait un exit immédiatement après, ou bien tu as commenté toutes tes règles bizarres ? :mrgreen:

Le but c’est d’obtenir un firewall totalement vierge :

# iptables -S -P INPUT ACCEPT -P FORWARD DROP -P OUTPUT ACCEPT[/quote]
Ben … :018

:116 je va recommencer … :033 et avec des # … :shhh:

Sinon tu sais, un bête copier/coller des 4 lignes iptables dans un terminal, ça marche aussi bien. Et comme ça t’as pas besoin de toucher à ton script. :wink:

Le résultat du tcptracereroute est sans appel : la box répond, donc le filtrage n’est pas sur la machine Debian. Par contre il n’y a plus rien après la box, donc c’est elle qui bloque, ou bien c’est le routeur de l’opérateur qui est à l’autre bout de la connexion ADSL. Tu peux comparer avec un tcptraceroute sur un autre port, comme le HTTP (80, qui est le port par défaut de tcptraceroute) par exemple. Il faudrait examiner les réglages de pare-feu de la box.

Bon si c’est toi qui le dis, je te fais confiance. :wink:

De retour …

Pas grave, c’est fait. :023

:~# /etc/init.d/firewall stop Flush des règles IpTables : Réinitialisation des règles du firewall... [OK] :~#

Après un bak, j’ai tous virés …

[code]:~# /etc/init.d/firewall restart
Flush des règles IpTables :
Réinitialisation des règles du firewall… [OK]
Application des règles IpTables :

  • Autoriser Temporairement toute connexion entrante ou sortante : [OK]
    Terminé.
    root@machine1:~# iptables -S
    -P INPUT ACCEPT
    -P FORWARD ACCEPT
    -P OUTPUT ACCEPT
    :~#[/code]

:~$ whois debian-fr.org connect: Connexion terminée par expiration du délai d'attente :~$

Effectivement, j’avais oublié le pare-feu de la box (depuis le temps … presque 3 ans)… :075

[code]:~# tcptraceroute whois.crsnic.net 80

Se
:~#
[/code]