Impossible de se connecter à des connexions d'hôte local


12

J'utilise Centos 6.5 avec les dernières mises à jour.

Mon problème est que chaque fois que j'essaie de me connecter à un service local, il se bloque par exemple:

wget

wget 127.0.0.1
--2014-03-11 12:43:42--  http://127.0.0.1/
Connecting to 127.0.0.1:80...
After a while timeout...

ssh

# ssh 127.0.0.1 -p 6060 -v
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 6060.
debug1: connect to address 127.0.0.1 port 6060: Connection timed out
ssh: connect to host 127.0.0.1 port 6060: Connection timed out

et il se bloque pour expirer.

Même chose avec telnet et même avec la connexion au serveur irc. Les connexions externes fonctionnent bien ...

netstat -tpln

# netstat -tpln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      589/sendmail        
tcp        0      0 127.0.0.1:6060              0.0.0.0:*                   LISTEN      520/sshd            
tcp        0      0 0.0.0.0:80                  0.0.0.0:*                   LISTEN      619/nginx           
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      478/sshd            
tcp        0      0 ::1:6060                    :::*                        LISTEN      520/sshd            
tcp        0      0 :::22                       :::*                        LISTEN      478/sshd            

netstat -rn

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 venet0
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 venet0

iptables

Je débusque les iptables sans succès. Formulaire de sortie iptables:

# iptables -nvL
Chain INPUT (policy ACCEPT 634 packets, 49819 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 517 packets, 47027 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Configuration en boucle

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/void 
    inet 127.0.0.1/32 scope host venet0
    inet 176.122.224.115/32 brd 176.122.224.115 scope global venet0:0

Le tournage de SELinux ne l'a amélioré avec rien.

ip route show table local

# ip route show table local
local 176.122.224.115 dev venet0  proto kernel  scope host  src 176.122.224.115 
broadcast 176.122.224.115 dev venet0  proto kernel  scope link  src 176.122.224.115 
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1 
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1 

traceroute

# traceroute 127.0.0.1
traceroute to 127.0.0.1 (127.0.0.1), 30 hops max, 60 byte packets
 1  localhost.localdomain (127.0.0.1)  0.029 ms  0.014 ms  0.012 ms

ping 127.0.0.1

fonctionne bien

# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.024 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.036 ms

La chose la plus étrange à ce sujet est que je peux me connecter à ssh, serveur nginx à partir d' une adresse externe (par exemple, un ordinateur à partir duquel je ssh'ing) sans problème.

Cela se produit après que le FAI a redémarré mon serveur. Ce qui peut être utile, c'est que le serveur a été fréquemment mis à jour sans redémarrage.


oh, Au fait, la configuration de la boucle est définie? , testez avec ip aou ifconfig.
PersianGulf

Yup est défini, pastebin.centos.org/8351 ou j'ai mal lu la sortie.
badray

@badray, vous avez modifié la configuration ip la dernière fois en utilisant ifconfig et les modifications n'ont pas été enregistrées, qu'est-ce qui donne un tracert 127.0.0.1?
Kiwy

@badray veuillez modifier votre question au lieu de copier des choses dans le bac précédent, il est correct d'avoir une question longue de miles si les informations sont importantes. et oui tu as raison traceroutenon tracert. Qu'est-ce ping 127.0.0.1qui te donne?
Kiwy

@Kiwy Ok, fait comme tu l'as demandé. Copie des sorties entières à questionner. Ping fonctionne très bien. Je viens de l'ajouter à la question.
badray

Réponses:


5

Selon la ifconfigsortie que vous avez publiée, l'adresse de bouclage est 127.0.0.1définie sur deux interfaces.

Essayer

ip addr del 127.0.0.1/32 dev venet0

et voyez si votre accès en boucle est restauré.


Maintenant, il ressemble à: pastebin.centos.org/8356 . Les connexions ne fonctionnent pas non plus.
badray

1
Veuillez ajouter le contenu de votre table de routage ( netstat -rn).
Flup


@Kiwy j'ai ajouté toujours des liens pastebin avec des sorties, car je suis un meilleur développeur que sysadmin, et je ne suis pas toujours sûr de lire correctement la sortie. EDIT: après la recherche netstat -rnne doit pas imprimer l'itinéraire localhost. ip route show table localdevrait, et il le fait, ce n'est pas le cas.
badray

5

J'avais exactement le même problème que vous décrivez. Je n'ai pas pu me connecter à aucun port d'écoute de l'hôte depuis le local, mais j'ai pu me connecter à distance.

La solution pour moi était de faire remonter l'interface lo qui était en panne pour une raison quelconque et ne montait pas au démarrage.

ifconfig lo up

Après avoir ramené l'interface et confirmé que je pouvais voir l' lointerface avec ...

ifconfig -a

J'ai pu continuer ma journée ... :)

J'ai remarqué que lors de l'exécution ip a, je n'ai pas vu 127.0.0.1 affecté à l'interface lo :. C'est ce qui m'a permis de comprendre que j'avais également besoin de cette interface pour fonctionner ...


Merci beaucoup pour cette réponse. Cela m'a guidé dans la bonne direction, qui était en lotrain de monter sans avoir d'adresse IP. ifdown lo && ifup loréparé pour moi, mais je pense toujours que c'était plutôt étrange.
Mitja

0

Flup a répondu à droite, mais j'ai trouvé cette question pour une autre raison. Je pense qu'une réponse alternative est nécessaire. Serveur, j'ai commencé à me connecter au socket IPv6 et je devrais utiliser une autre adresse pour me connecter comme:

nc ::1 8080

ou

curl http://[::1]:8080/
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.