4 votos

Puerto/s de reenvío a una IP externa transparente iptables (extremo remoto debe ver la IP de origen real)

La pregunta es simple, pero creo que la respuesta no podría ser, ya que fue a través de un sinnúmero de temas relacionados con el hormigón no respuesta.

Quiero reenviar un puerto 1234 de x.x.x.x a y.y.y.y (tanto en internet en lugares diferentes, es decir, y.y.y.y no es una IP interna como 10.a.b.c etc) de una manera que y.y.y.y es capaz de obtener el código fuente original de IP de conexión de a x.x.x.x.

Ahora ve x.x.x.x como el origen de la IP con la costumbre de SNAT o la MASCARADA de reglas. Si y.y.y.y algunas IP interna (como la de un lxc contenedor de ejecución en x.x.x.x) las mismas reglas de trabajo y el contenedor es capaz de ver la IP de origen, pero no si y.y.y.y es externo.

Esto puede ser logrado de alguna manera?

4voto

Nick Dixon Puntos 154

Con sólo NAT – no. Los paquetes IP sólo tiene una "fuente" de campo.

  • Si usted hace iptables mantener el original en la dirección del cliente (DNAT), a continuación, y.y.y.y intentará enviar las respuestas directamente a la original cliente (que piensa que está hablando con x.x.x.x y no esperar que todos los paquetes de y.y.y.y).

  • Si usted hace iptables poner su dirección como la nueva fuente (DNAT+SNAT), entonces y.y.y.y no sé la fuente original de la dirección.

(Esto es en realidad el mismo problema que con el intento de puerto-adelante desde la LAN a la misma LAN, y el 2º método es llamado 'NAT hairpinning' o 'NAT reflexión'.)


Para realizar este trabajo, usted necesita un túnel VPN entre x.x.x.x y y.y.y.y – envoltura de los paquetes originales de recibir, sin ningún tipo de cambios, dentro de otro paquete IP que se envía a y.y.y.y (que, a continuación, retire el catéter de paquetes y ver la fuente original).

Por supuesto, esto significa que usted necesita privilegios de root en ambos sistemas con el fin de configurar el túnel. Además, el destino (y.y.y.y) las necesidades de apoyo a la política de "enrutamiento" – en Linux y FreeBSD pf son capaces de esto. Se necesita una regla que voy a la ruta todo a través de la VPN si la dirección de origen es una dirección de VPN.

Usted todavía necesita la regla DNAT de iptables, pero su 'destino' será y a la VPN de la dirección, no la dirección pública. Usted puede utilizar cualquier túnel/tipo de VPN para esto, desde el básico "IP-in-IP" GRE para OpenVPN para WireGuard. Por ejemplo:

  • x.x.x.x

    Abrir el túnel:

    ip link add gre-y type gre local x.x.x.x remote y.y.y.y ttl 64
    ip link set gre-y up
    ip addr add 192.168.47.1/24 dev gre-y
    

    Agregar puerto de reenvío de la regla, como en una LAN:

    iptables -t nat -I PREROUTING -p tcp --dport 1234 -j DNAT --to-destination 192.168.47.2
    
  • y.y.y.y

    Abrir el túnel:

    ip link add gre-x type gre local y.y.y.y remote x.x.x.x ttl 64
    ip link set gre-x up
    ip addr add 192.168.47.2/24 dev gre-x
    

    Asegúrese de que funciona:

    ping 192.168.47.1
    

    Establecer una política de enrutamiento, por lo que las respuestas (y sólo las respuestas) sobre el túnel:

    ip route add default via 192.168.47.1 dev gre-x table 1111
    ip rule add pref 1000 from 192.168.47.2 lookup 1111
    

(Para usar otro túnel/tipo de VPN, sólo sustituir el "abrir el túnel".)

3voto

RalfFriedl Puntos 131

No, usted no puede lograr eso. El problema es que la ruta no va a funcionar.

Host E (externo) envía un paquete al Host F (forwarder). F , se envía el paquete con la misma fuente para alojar D (destino). Esta parte no funciona, si D es interno o externo.

Ahora D debe devolver una respuesta, y la envía a la dirección de origen del paquete, que es E.

  • Si D es un host interno y F es la puerta de enlace predeterminada para D, entonces el paquete pasa F, donde la fuente D en la respuesta de paquetes se cambia a F. Host E ve un paquete que viene de F, y todo está bien.
  • Si D es un host externo, a continuación, F no será la puerta de enlace predeterminada para D, y, por tanto, D le enviará la respuesta directamente a E. Host E la respuesta de D, pero espera una respuesta de F, y para ello, descarta el paquete de D. Host E volverá a intentar un par de veces, volverá a descartar la respuesta de la equivocada dirección de origen, y el tiempo de espera.

2voto

porto alet Puntos 315

Probablemente usted no puede lograr esto porque la dirección de origen se utiliza para la devolución de paquetes, por lo que si la dirección de origen está detrás de NAT, no puede ser alcanzado a partir de la más amplia de Internet.

Hay al menos 2 soluciones (que requieren de software adicional y configuración) de uso común - La primera es utilizar una VPN para eludir el router, o, alternativamente, utilizar entre el router y el destino para que el destino pueda saber cómo llegar a la fuente.

En el caso de HTTP y HTTPS, no usar IPTABLES las reglas de firewall, uso una (transparente o regular) proxy en el router en su lugar, y tiene el servidor proxy añade una X-FORWARDED-FOR cabecera, que la aplicación externa puede tener acceso y procesar.

Dependiendo de su aplicación exacta y firewall, también podría ser posible para marcar una "relativa" dirección IP interna modificando el puerto de origen de la solicitud (que todavía va a venir de los routers dirección, pero usted puede ser capaz de obtener una idea de qué sistema de detrás del router envía basada en el puerto de origen). Yo no he visto esto en la práctica.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: