2011/2/24 Mariano Cediel mariano.cediel@gmail.com
El día 24 de febrero de 2011 04:13, Eduardo Grosclaude eduardo.grosclaude@gmail.com escribió:
2011/2/23 Mariano Cediel mariano.cediel@gmail.com
Hola Mariano
El equipo X está en una red con direcciones privadas, y estas direcciones
no
se publican a través de Internet. Por lo tanto si el SSH al equipo X
(desde
el equipo Y) resulta posible, y el equipo Y no se encuentra en ninguna de las RED1 de tu ejemplo entonces es porque el routerB hace NAT o
traducción
de direcciones hacia adentro (a veces llamado "port forwarding").
Para cada paquete proveniente de Y por Internet, el routerB reemplazará
la
dirección origen por 192.168.1.B antes de entregarlo a la red local. Así
le
presentará a X las conexiones entrantes como si hubieran sido originadas
en
routerB. X generará las respuestas dirigidas a routerB. El routerB al recibir la respuesta cumplirá la segunda parte del mecanismo de NAT, devolviendo el paquete a Y con la dirección origen nuevamente modificada, para reflejar la dirección IP pública a la cual apuntó Y.
X no ruteará la respuesta por routerA, su gateway por defecto, porque la entrega es local, ya que tanto 192.168.1.X como 192.168.1.B están en la misma red.
Es que tengo un caso en el que esto no se cumple, y no entiendo muy bien por qué.
Si puedes danos más detalles, posiblemente el caso es el de port
forwarding?
No, son dos cutre-routers adsl de ISP, que permiten la redirección de puertos, sin más. Y no hacen la traslación de IPs, ya que cuandomiramos quien esté conectado en el CENTOS (con w o con netstat), se ve la IP PUBLICA del usuario, no la IP privada del router
Y durante esas sesiones aparece en el equipo X una ruta hacia Y a través de routerB? Si es así, posiblemente se trate de un caso de ICMP REDIRECT por parte de routerA...
Acá http://www.networksorcery.com/enp/protocol/icmp/msg5.htm hay unas notas sobre REDIRECT con punteros a las RFCs correspondientes.