6 votos

Todas las conexiones de esta red se atascan en estado SYN_RECV, conexiones desde mi teléfono de casa o haz establecidas correctamente

Mi servidor (un linode VPS) de repente empezaron a tiempo de espera en cada solicitud de ayer.

Soy bastante inexperto en la creación de redes y me encantaría aprender un proceso para la depuración de estos problemas de conectividad.

Lo que me confunde es que ayer, algunas personas (mi teléfono, mi casa, los amigos en casa) siempre podría acceder a la página y veo con netstat que se ha establecido una conexión. He desactivado firwalls y configurar iptables para que acepte todas las conexiones para descartar cualquier extraño auto reglas de listas negras de nuestra IP. No estoy seguro si es relevante, pero un traceroute desde la red local veces - traceroute de algunas máquinas fuera a encontrar a mi servidor.

He confirmado varias configuraciones son correctas mediante la comparación de la configuración de mi servidor de desarrollo que está funcionando correctamente.

Los siguientes archivos que coincida con mi entorno dev (con excepción de sus respectivas direcciones ip):

/etc/hosts 
/etc/hosts.allow
/etc/hosts.deny
/etc/networking/interfaces 
ifconfig

Apache está escuchando en el puerto 80 y el programa de instalación es exactamente el mismo que el de mi servidor que funcione.

# server that doesn't work:
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      22008/apache2
tcp        0      0 69.164.201.172:80       71.56.137.10:57487      SYN_RECV    -

# server that does work
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      3334/apache2
tcp        0      0 72.14.189.46:80         71.56.137.10:57490      ESTABLISHED 20931/apache2

Mi intento de comprensión

Cada vez que se carga la página de una vez, netstat -an | grep :80 revela todas las conexiones en SYN_RECV estado.

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 69.164.201.172:80       71.56.137.10:56657      SYN_RECV
tcp        0      0 69.164.201.172:80       71.56.137.10:56669      SYN_RECV
tcp        0      0 69.164.201.172:80       71.56.137.10:56671      SYN_RECV

Por lo que el SYN_RECV significa que el servidor está a la espera de una ACK a ser enviados desde el cliente.
¿Cómo puedo depurar si un ACK se envía de vuelta? ¿Cómo puedo depurar donde esta comunicación está fallando?

He aquí lo que un tcpdump se parece a cuando intento cargar la página una vez.

En el pegar a continuación, mi servidor es constantemente el envío de paquetes al cliente y al no recibir una respuesta.

¿Qué significa esto? Que el cliente no está recibiendo la respuesta? O tal vez me estoy tragando la respuesta en algún lugar en el servidor? ¿Cómo puedo saber a reducir el culpable?

tcpdump -i eth0 -n -tttt port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
2011-05-25 20:12:54.627417 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
2011-05-25 20:12:54.627512 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:54.814463 IP 69.164.201.172.80 > 71.56.137.10.57157: Flags [S.], seq 604630211, ack 496040070, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:55.214482 IP 69.164.201.172.80 > 71.56.137.10.57158: Flags [S.], seq 998358186, ack 2224730755, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:57.624737 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
2011-05-25 20:12:57.624793 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:12:59.014477 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:13:03.618790 IP 71.56.137.10.57160 > 69.164.201.172.80: Flags [S], seq 382527960, win 8192, options [mss 1460,nop,nop,sackOK], length 0
2011-05-25 20:13:03.618866 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:13:05.014514 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0
2011-05-25 20:13:17.014504 IP 69.164.201.172.80 > 71.56.137.10.57160: Flags [S.], seq 1330600505, ack 382527961, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 6], length 0

tcpdump para servidor funcional

Al mirar en el tcpdump para mi servidor funcional, veo de nuevo y cuarto de la comunicación entre el servidor y el cliente.

00:00:00.000000 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [S], seq 34114118s [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
00:00:00.000110 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [S.], seq 2454858 win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0
00:00:00.061827 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [.], ack 1, win 100:00:00.004292 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [P.], seq 1:597, ngth 596
00:00:00.000074 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], ack 597, win00:00:00.493990 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], seq 1:2921, ngth 2920
00:00:00.000024 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [P.], seq 2921:30, length 98
00:00:00.065135 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [.], ack 3019, wi00:00:00.034766 IP 71.56.137.10.57260 > 72.14.189.46.80: Flags [P.], seq 597:12925, length 699
00:00:00.000035 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [.], ack 1296, wi00:00:00.000457 IP 72.14.189.46.80 > 71.56.137.10.57260: Flags [P.], seq 3019:328, length 211
00:00:00.019196 IP 71.56.137.10.57262 > 72.14.189.46.80: Flags [S], seq 10674886s [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0

Cualquier sugerencias, explicaciones o comentarios se aprecian enormemente, por lo que puedo entender TCP un poco más y espero ser un poco más útil la próxima vez tengo que depurar un problema como este.

Gracias!

7voto

sysadmin1138 Puntos 86362

A esta cansado de los ojos, parece que hay algún tipo de problema de enrutamiento de cerca el servidor en cuestión. Los paquetes vienen en a lo largo de una ruta, pero parece que salen a través de una ruta diferente y algo de estado es en ese camino y dejar caer el raro "ACK sin SYN" paquetes.

He tenido que esto ocurra a mí una vez. Lo que terminó siendo el caso era que el servidor ha tenido una mala máscara de red, de modo que cuando el tráfico de la subred salieron, se emitirá una solicitud de ARP para obtener la dirección MAC del nodo. Por desgracia para mí, tanto en el router y nuestro equilibrador de carga fueron habilitados para Proxy-ARP, y el equilibrador de carga era un poco más rápido en el gatillo que el router. Así que los paquetes SYN llegó a través del router, pero estaban tratando de salir de la subred a través del equilibrador de carga. Como el LB no tienen una conexión de paquete ACk, se dejó caer en el suelo.

En el caso de que algunos juiciosa traza las rutas pueden iluminar la red de la ruta de los problemas. Desde el servidor afectado, intento de traceroute a la IPs que causa el problema, y hacer lo mismo de los mismo IPs. Si usted está recibiendo diferentes rutas de acceso, que puede ser lo que es.

-1voto

tcpdump Puntos 1

sólo tenía el mismo problema.

En mi caso esto fue un error de configuración de red.

servidor se ha configurado con 10.0.1.111 255.255.254.0 y cliente se configuran con 10.0.0.15 255.255.255.0. Cambiar la máscara de red en el lado del cliente a 23 solucionó el problema.

Esto podría ayudar a la esperanza.

Mira tcpdump

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X