xdebug depuración remota con el puerto 9000 reenviado a través del túnel ssh: ¿cómo hacer que funcione?

Question

Tengo XAMPP 1.7.3a ejecutándose en una instancia de 32 bits "Amazon Linux" (derivada de Centos) en la nube de Amazon EC2. Descargué/construí/instalé XDEBUG 2.1.0. Los artículos pertinentes de phpinfo() mira salida como esta:

Directive       Local Value Master Value 
xdebug.idekey      ECLIPSE_DBGP ECLIPSE_DBGP 
xdebug.default_enable    On   On 
xdebug.remote_autostart   On   On 
xdebug.remote_connect_back  Off   Off 
xdebug.remote_cookie_expire_time 3600   3600 
xdebug.remote_enable    On   On 
xdebug.remote_handler    dbgp   dbgp 
xdebug.remote_host    127.0.0.1 127.0.0.1 
xdebug.remote_mode    req   req 
xdebug.remote_port    9000   9000 
xdebug.remote_log     /opt/lampp/logs/xdebug_log 
               /opt/lampp/logs/xdebug_log 

que acceden a la máquina Linux desde un ordenador portátil Windows que se ejecuta XP SP3, usando el cliente SSH PuTTY en la versión 0.60. También en la computadora portátil instalé Eclipse PDT (Helios Service Release 1 Build ID: 20100917-0705), y creo que lo configuré correctamente para hacer la depuración remota de XDEBUG usando el puerto 9000. Digo que piensa, porque He tenido dificultades para descubrir cómo hacerlo y cómo usar Eclipse PDT en general. Pero logré configurarlo y trabajar para la depuración "remota" del código PHP ejecutado por las páginas web servidas usando XAMPP para Windows 1.7.3 en localhost (127.0.0.1), usando el puerto 9000. El resultado de phpinfo() para el servidor en el ordenador portátil que PDT es capaz de depurar es el mismo que el anterior, con excepción de:

xdebug.idekey  my_username  no value 
xdebug.remote_host localhost  localhost 
xdebug.remote_log no value  no value 

estoy bastante seguro de que estas diferencias no están relacionados con el problema. De hecho, xdebug.idekey era originalmente "root novalue" en Linux, que luego cambié a ECLIPSE_DBGP editando php.ini y estableciendo la variable de entorno DBGP_IDEKEY en el script sudo-ed que inicia apache, en vano espero que las cosas funcionen.

Tengo cortafuegos y un enrutador NAT entre la computadora portátil y la caja Linux. Así que estoy tratando de usar el reenvío de puertos a través de un túnel PuTTY ssh para hacer que el XDEBUG de Linux converse con el PDT de Windows. He usado el reenvío X11 con PuTTY durante un par de meses sin problemas. He definido el túnel en la masilla con puerto local 9000 remitido al puerto 9000 en la máquina Linux, y el puerto 9000 en la máquina Linux remitido al puerto 9000 127.0.0.1, el panel túnel masilla presentados:

L9000 host...amazonaws.com:9000 
R9000 127.0.0.1:9000 

Buscando en el registro de eventos de la masilla cuando el túnel está configurado, no parece haber ningún problema:

2010-11-16 18:07:59 Local port 9000 forwarding to host...amazonaws.com:9000 
2010-11-16 18:07:59 Requesting remote port 9000 forward to 127.0.0.1:9000 
2010-11-16 18:07:59 Remote port forwarding from 9000 enabled 

Pero entonces, cuando voy a PDT y haga clic en Depurar en una configuración que especifica el servidor web remoto, PDT muestra la actividad de fondo en la esquina inferior derecha que se atasca al 57%, y si hago clic en el ícono para ir a la vista de progreso, eso muestra "Iniciando: esperando la sesión de XDebug".

Cuando esto sucede, la masilla de registro de eventos muestra:

2010-11-16 19:05:42 Received remote port 9000 open request from 127.0.0.1:54474 
2010-11-16 19:05:42 Attempting to forward remote port to 127.0.0.1:9000 
2010-11-16 19:05:42 Forwarded port opened successfully 
2010-11-16 19:05:42 Opening forwarded connection to host...amazonaws.com:9000 
2010-11-16 19:05:42 Forwarded connection refused by server: Connect failed [Connection refused] 
2010-11-16 19:05:42 Forwarded port closed 

En la máquina Linux,/var/log/secure sólo demuestra:

Nov 16 19:01:51 ip-10-194-9-67 sshd[14555]: error: connect_to host...amazonaws.com port 9000: failed. 

He comprobado mi/etc/ssh/sshd_config, y creo que está bien, incluso cambiándolo explícitamente a "AllowTcpForwarding yes", aunque se supone que es el predeterminado. En mis búsquedas en la web para una solución, me llegó a través de una linuxquestions posting siempre que la respuesta definitiva dice algo bastante críptica sobre sshd necesidad de resolver un nombre de host:

esto parecía solucionarlo: El nombre de host siempre ha sido dominio- serv, ya que siempre he pensado en mi enrutador como dominio.com ... así que después de ejecutar hostname domain.com ... ¡bam! Finalmente funciona ...

Supongo que a veces es demasiado simple. sshd tenía que estar resolviendo el dominio.com a mi enrutador, ergo la conexión falló.

Parece que esto podría estar relacionado con mi problema, pero no tiene sentido para mí, y como es bastante antiguo, y el autor tampoco pareció entenderlo, pensé que podría preguntar aquí en lugar de allí ...

Me di cuenta de que un similar question se le preguntó en este foro hace casi un año que obtuvo solo una respuesta de 0 valores, presumiblemente porque la pregunta era tan carente de detalles como para ser incontestable. Espero que este tenga suficiente información, y no sea tan larga, para que alguien pueda dirigirme correctamente. Después de leer las preguntas frecuentes y de cómo hacer una pregunta, no me resultó del todo obvio si el uso correcto del foro era publicar algo en esa pregunta original mal hecha pero idéntica al contenido, o publicar esta nueva: Estoy seguro de que alguien me dirá cuál fue la elección correcta sobre eso :-)

Me he vuelto loco con esto, y sospecho que es algo bastante obvio para alguien con experiencia. Soy un novato en la mayoría de estas cosas (PHP, programación web, administrador de red y este foro), aunque no a la anticuada programación C y configuración de Linux y Windows a nivel de usuario.

Answer 1

¿Qué embarazoso, al parecer, mi configuración de reenvío de puertos era algo que solo un novato de la red haría? Supongo que decidí que dado que el Xdebug que se ejecuta en el servidor web necesita hablar con el cliente de depuración PDT en la computadora portátil, y el cliente de depuración PDT en la computadora portátil también necesita hablar con Xdebug en el servidor, y solo hay un número de puerto (9000), que por lo tanto necesitaba reenviar el puerto local 9000 al puerto remoto 9000, y también reenviar el puerto remoto 9000 al puerto local 9000; Estaba confundiendo la dirección del tráfico con qué lado está el cliente iniciando una conexión (bidireccional) a un puerto específico que está escuchando el lado del servidor.

Lo que parecía estar sucediendo era que el depurador de PDT que se ejecutaba en la computadora portátil se quedó atascado esperando que Xdebug se ejecutara en Linux para establecer una conexión. Como realmente no podía pensar en una situación en la que Xdebug tendría que estar escuchando el puerto 9000, esperando que el depurador PDT iniciara una conexión (en vez de eso, estaría esperando que el depurador PDT le enviara un comando a través de una conexión que tenía ya fue establecido por su puerto de apertura 9000 cuando vio el parámetro XDEBUG_SESSION en la solicitud), decidí deshacerme del reenvío del puerto local 9000 al puerto remoto 9000. Lo hice y, de repente, PDT recibía el conexión enviada desde el servidor Linux, y la depuración procedió normalmente desde allí.

Pero lo que todavía no está claro en mi mente es por qué teniendo el reenvío adicional en realidad causó un problema. ¿No podría ser posible que un par de programas en diferentes hosts funcionen de manera tal que, dependiendo del estado, a veces uno sea el oyente y, a veces, el otro? Siempre que el reenvío no cause que ambos intenten escuchar en el mismo puerto al mismo tiempo, espero que esté bien.

La conclusión es que las cosas parecen estar funcionando ahora debido a una simplificación que hice, pero me gustaría entender por qué la complejidad innecesaria en realidad causaba un problema. He leído muchas cosas, incluida la excelente explicación de ssh y tunneling en the O'Reilly book, pero sigo sin entenderlo.