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".

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.

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