Re: Inexplicable broken pipe entre dos subredes bajo mismo LAN
El 24 de marzo de 2014, 23:54, Santiago Liz <lizsanti@gmail.com> escribió:
>
> El día 23 de marzo de 2014, 6:32, Roberto <i32lelor.debian@gmail.com> escribió:
> > Administro una red LAN donde siempre que puedo aplico Debian a la ecuación.
> >
> > El servidor que hace de gateway hace de firewall y registra log determinado
> > trafico. Tiene dos interfaces br0 y br0:1 con 192.168.0.2 y 192.168.2.1. Uso
> > un alias por no disponer de dos tarjetas de red, y uso br0 porque en dicho
> > equipo uso VirtualBox.
>
> > Tengo un servidor con jenkins(Debian) en la 192.168.0.8 el cual conecta por
> > ssh a dos nodos esclavos, 192.168.2.19(Centos) y 192.168.2.21(Ubuntu). El
> > primero tiene como gateway a 192.168.0.2 y el segundo a 192.168.2.1.
> >
> > Con Ubuntu ningún problema con el trafico de red pero con Centos
> > aleatoriamente ocurre un broken pipe de una sesión ssh, lo único que se me
> > ocurrió despues de días dando cabezasos es pasar ese nodo Centos a la subred
> > con ip 192.168.0.9 y todo arreglado. Abajo pegaré el log de un broken pipe.
> >
> > ¿Hay alguna idea para en esta situación se produzca un broken pipe? Y he
> > configurado Centos para no usar Gssapi, DenyDNS, y lo típico en cliente para
> > evitar un time out.
> >
>
> Si las dos redes que tienes definidas comparten físicamente el mismos
> medio, es probable que el cliente ssh en una de las redes al
> conectarse al servidor en la otra red, envíe los paquetes hacia la mac
> address de su default gateway y tu firewall/router reenvíe esos
> paquetes al servidor ssh. Lo lógico sería pensar que el servidor ssh
> al establecer la conexión envíe los paquetes corresponedientes de
> regreso hacia el cliente también por medio de su default gateway.
> Por alguna razón (que no me puse a investigar), al compartir ambos
> (cliente y servidor) el mismo medio físico, uno de los dos aprende la
> mac address del otro y termina enviando los paquetes en forma directa
> sin intervención del defualt gateway, esto ocasiona un camino
> asimétrico, que ante la presencia de un firewall statefull provoca el
> corte de comunicación.
>
>
>
> > jenkins@192.168.2.19's password:
> > debug3: packet_send2: adding 64 (len 60 padlen 4 extra_pad 64)
> > debug2: we sent password packet, wait for reply
> > debug1: Authentication succeeded (password).
> > Authenticated to 192.168.2.19 ([192.168.2.19]:22).
> > debug1: channel 0: new [client-session]
> > debug3: ssh_session2_open: channel_new: 0
> > debug2: channel 0: send open
> > debug1: Requesting no-more-sessions@openssh.com
> > debug1: Entering interactive session.
> > debug2: callback start
> > debug2: client_session2_setup: id 0
> > debug2: fd 3 setting TCP_NODELAY
> > debug3: packet_set_tos: set IP_TOS 0x10
> > debug2: channel 0: request pty-req confirm 1
> > debug1: Sending environment.
> > debug3: Ignored env SHELL
> > debug3: Ignored env TERM
> > debug3: Ignored env USER
> > debug3: Ignored env LS_COLORS
> > debug3: Ignored env MAIL
> > debug3: Ignored env PATH
> > debug3: Ignored env PWD
> > debug1: Sending env LANG = es_ES.UTF-8
> > debug2: channel 0: request env confirm 0
> > debug3: Ignored env SHLVL
> > debug3: Ignored env HOME
> > debug3: Ignored env LOGNAME
> > debug3: Ignored env _
> > debug2: channel 0: request shell confirm 1
> > debug2: callback done
> > debug2: channel 0: open confirm rwindow 0 rmax 32768
> > Write failed: Broken pipe
> >
> >
> > --
> > To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
> > listmaster@lists.debian.org
> > Archive: [🔎] 532EAA40.5060506@gmail.com">https://lists.debian.org/[🔎] 532EAA40.5060506@gmail.com
> >
>
> Saludos,
> Santiago.-
Pues efectivamente, las rutas son asimétrica como he mostrado en los
resultados en email anterior. Y he encontrado como las distros
RHEL/Centos no aceptan el tráfico asimétrico a partir de las release
5. En esta url hablan de ello
https://access.redhat.com/site/solutions/53031 .
Esto lo desconocía ya que suelo montar todo lo que puedo bajo
Debian!!!! Ya solo me queda investigar el porqué en la misma LAN se
produce éste tráfico asimétrico.
Reply to: