El 24/03/2014 23:54, Santiago Liz escribió:
El día 23 de marzo de 2014, 6:32, Roberto <i32lelor.deb...@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-sessi...@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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
Archive: https://lists.debian.org/532eaa40.5060...@gmail.com
Saludos,
Santiago.-
Es decir, que aun teniendo bien la configuración de cada equipo
apuntando al gateway 192.168.0.2 en el caso de LAN puede realizar el
camino directo???? esto lo voy a ver con mtrr y os detallo que ocurre.
Informar, que hay otro gateway 192.168.0.1, pero este no es usado por
ninguno de estos nodos y sólo por el servidor central para el tráfico
hacia internet.
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5331418d.6010...@gmail.com
