PHP IP local del cliente

[Kaxperday]

Ojj otra vez a escribir el post, odio el mensaje ese de que se te ha cerrado sesión justo cuando le das a enviar y tienes que iniciar sesión porque sino no te deja ni volver atrás porque te sale el login cargues lo que cargues inicias sesión y ya no puedes recuperar el mensaje OJJJ.

Bueno al tema:

Código (php) [Seleccionar] Expandir


<?php 
if(isset($_POST["ip"])){
echo "IP a la que trata de conectarse: {$_POST["ip"]}";
echo "<br>";
echo "La IP de su router es: {$_SERVER['REMOTE_ADDR']}";
echo "<br>";
echo "Su IP en su red local es: {$_SERVER['HTTP_X_FORWARDED_FOR']}";
echo "<br>";
echo "El puerto que utiliza para la conexión es: {$_SERVER['REMOTE_PORT']}";
echo "<br>";
}
?>


¿Por qué $_SERVER['HTTP_X_FORWARDED_FOR'] no contiene nada? ¿está deprecada la manera de obtener la ip local del cliente? Mi IP local es 192.168.1.34 por ejemplo, ¿por qué entonces no se muestra en el script? ¿y como conseguirla, pues me es necesaria y necesito coseguirla siempre que exista a ser posible?.

¿Alguna idea?.

Un saludo y gracias.

Edito: Reading... https://www.sitepoint.com/community/t/php-code-to-get-local-computer-ip-address/5697/9
https://en.wikipedia.org/wiki/TCP_hole_punching

Ahora entiendo, ¿puede depender de la NAT? Para conseguir conectar un equipo con otro necesito  "predictable NAT" en al menos uno de los equipos sino no se podrá producir la conexión entre ellos. Ya que el servidor no conocerá la ip local de un equipo del par que producirán conexión. Como pone en la tabla de la NAT en el último link.

Más interesante todavía entonces.

[MinusFour]

HTTP_X_FORWARDED_FOR viene de la cabecera X-Forwarded-For. Tiene muy poco que ver con la IP local.

En los paquetes que envia el cliente no figura su IP local. Al hacer el NAT el source IP es cambiado por la IP "publica".

[Kaxperday]

HTTP_X_FORWARDED_FOR viene de la cabecera X-Forwarded-For. Tiene muy poco que ver con la IP local.

En los paquetes que envia el cliente no figura su IP local. Al hacer el NAT el source IP es cambiado por la IP "publica".

Pero yo tenía una manera de conseguir la IP local que tenía en la red a partir de PHP ya no me acuerdo (espero que no fuese con js... no creo).

Claro, ¿pero puede haber alguna situación en la que si que se pueda conseguir la IP local del cliente del lado del servidor?.

Saludos y gracias

[MinusFour]

Pero yo tenía una manera de conseguir la IP local que tenía en la red a partir de PHP ya no me acuerdo (espero que no fuese con js... no creo).

Claro, ¿pero puede haber alguna situación en la que si que se pueda conseguir la IP local del cliente del lado del servidor?.

Saludos y gracias

Con JS si hay una forma, atraves de WebRTC:

https://www.perfect-privacy.com/webrtc-leaktest/

Pero del lado del servidor no tengo idea. Si revisas las cabeceras de los paquetes desde la capa IP (en el servidor) te puedas dar cuenta que en ningún lado aparece la IP local a menos que estés usando la red local.

[Kaxperday]

Bueno pensandolo bien no es necesario para lo que pretendo, ya que podría enviarse directamente la dirección ip local del cliente al servidor y ya está, la calcula el cliente y la pasa :X

De todas maneras si se puede obtener con js como era de esperar, quizás se pueda mandar esa ip calculada con el js con un XMLHttpRequest al server y que lo cargue en una variable, y ya está pero no estoy seguro de ello, no conozco mucho js y sus límites.

¿Si se puede pasar cualquier cosa de js por XMLHttpRequest(), dónde está la protección del cliente?, no sé ¿es es eso que digo verdad?, un saludo y gracias.

[kub0x]

Buenas Kaxperday,

supongo que quieres montar un servidor tipo STUN,TURN o ICE para recibir las IPs de los integrantes de la red e interconectarlos para que de esta forma intercambien información independientemente de la configuración de su NAT.

Para ello recomiendo PHP Sockets, HTTP tiene un fin y personalmente no cumple las necesidades del propósito. Con UPnP, XML y UDP puedes determinar la IP privada/pública si el router lo tiene activo, además de poder abrir puerto. También tienes NAT-PMP y PCP para el mismo fin. UPnP se utiliza para hacer queries a dispositivos y administrarlos remotamente.

Volviendo al tema de STUN, bueno, en términos p2p se lo conoce como Rendezvous, pues une varios clientes. Mantienes un mapa con un par de claves, IP pública e IP local y lo vas llenando con la info que recibes en el Rendezvous. Si el cliente no tiene UPnP en NAT entonces coge su IP a través de las funciones de sockets. Ojo, UPnP te da la IP real, da igual que esté tras VPN, algo que escandalizó bastante puesto que Chrome y Firefox integraban este protocolo, se puede deshabilitar y es de lo que te habla MinusFour (WebRTC).

Si varios clientes tienen la misma IP pública, lo notarás ya que el map tiene una previa entrada, así que conectarás a esos dos clientes mandándoles la IP privada correspondiente, sino emplea la pública.

Para punchear NAT sin PCP/PMP/UPnP nos queda el hole punch, que es facílismo de implementar. Primero el cliente debe probar la conectividad contra el otro extremo, si se puede conectar de primeras bien, sino el extremo le está enviando RST ya que NAT no deja pasar si no existe entrada para esa conexión. En caso de RST hacer connect() en ambos extremos hasta que llegue un punto en que ambas NAT mapeen las entradas, ejemplo:

A y B son los dos clientes. El NAT de A marcará: A:1234 - B:1234
El NAT de B marcará: B:1234 - A:1234

Claro está que estos mapeos suceden antes de enviar un RST, por eso sucede este comportamiento, es explotar NAT. Este seria el caso de port restricted NAT, en caso de Symmetric NAT consulta http://think-like-a-computer.com/2011/09/19/symmetric-nat/ puesto que este hilo no va de tipos de NAT.

Saludos y olvídate de HTTP