Tengo una Raspberry Pi en ejecución que usamos en la oficina para pequeños proyectos de prueba que no queremos en nuestro servidor de desarrollo principal. Está ejecutando apache. El DNS se maneja a través de Cloudflare, pero en modo Solo DNS. Actualmente, no existe ninguna restricción de IP mientras realizo la prueba. El registro A mysite.domain.tldapunta a mi dirección IP estática 123.123.123.123y solo un enrutador/módem de fibra comercial estándar se encuentra entre Internet y el Pi.
Cuando visito mysite.domain.tlddesde, por ejemplo, mi teléfono sin wifi, aparece la IP del operador de telefonía móvil. Cuando wgetdesde un servidor remoto,es'La IP aparece en los registros. Todo funciona como se esperaba.
Sin embargo, cuando voy mysite.domain.tlddesde la misma red en la que se encuentra el Pi, Apache registra la IP de la puerta de enlace del enrutador 192.168.1.1. Esperaría ver mi dirección IP pública, porque mi conexión al nombre de dominio se resuelve, a través de Cloudflare, en la IP pública. Pero en lugar de eso veo una IP de red local en los registros.
No hay nada configurado /etc/hosts(estoy en macOS) y en el enrutador, solo el reenvío de puertos para conexiones desde el puerto 443 son enrutadores al Pi en el mismo puerto; nada relacionado con el nombre de dominio es una referencia en ninguna parte. Cuando hago ping mysite.domain.tldme da elLlamarada de nubeDirección IP, que es lo que esperaría.
Parece que en algún lugar de la cadena, el hecho de que mi dirección IP y la dirección IP pública del Pi coinciden, por lo que anula la IP con la IP de la puerta de enlace interna.¿Qué está pasando realmente aquí?Nomenteper se, solo quiero asegurarme de poder confiar en el hecho de que 192.168.*se puede confiar en las IP al configurar la restricción de IP en el firewall.
Nota: Cloudflare no envía CF-Connecting-IP y encabezados similares aquí, supongo que eso solo sucede cuando no está en modo Solo DNS. y esopareceser solo cuando uso la misma conexión de red que usa el Pi.
Respuesta1
Su enrutador ejecuta Linux y este comportamiento es fácil de implementar en cualquier distribución de Linux estándar. Puedo adivinar qué reglas deben estar presentes en el firewall de su enrutador para que funcione así. Pero tenga en cuenta que esto es sólo una especulación, no sabemos exactamente cómo se ven las reglas en la realidad.
Cuando reenvió un puerto a su servidor web, agregó una regla DNAT específica, que probablemente se vea así:
iptables -t nat -A PREROUTING -p tcp -d <your-external-address> --dport 443 -j DNAT --to-destination <raspberry-pi-address>
En palabras, esto significa: "antes de decidir si este paquete está destinado al dispositivo o debe reenviarse, verifique si la dirección de destino del paquete es su dirección externa y el puerto de destino es 443. Si coincide, cambie la dirección de destino a la LAN de Raspberry Pi DIRECCIÓN". Tenga en cuenta que esta regla no filtra por interfaz.
También definitivamente tiene la regla de tipo SNAT (para proporcionar acceso a Internet para la LAN), probablemente se vea así:
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE
En otras palabras, después de que el enrutador decide dónde debe ir el paquete, antes de enviarlo, cambia su dirección de origen a cualquier dirección que tenga una interfaz de salida (si el paquete se envió desde la LAN). Una vez más, una interfaz no filtra nada.
Ahora considere su conexión HTTPS. Estás especificando el nombre del host en el navegador, ¿verdad? Lo configura para que se resuelva en la dirección externa de su enrutador, que se convierte en la dirección de destino. Su dirección de origen está dentro de LAN. Entonces, parece que ambas reglas se aplican a los paquetes de su conexión.
Al procesarlos, el enrutador encuentra por primera vez la regla DNAT, verifica la dirección y el puerto de destino y decide cambiar la dirección de destino a la de Raspberry Pi. Luego descubre que la interfaz por la que debe salir el paquete es LAN. Luego verifica el paquete parcialmente traducido con la segunda regla y descubre que la dirección de origen es de LAN. Por lo tanto, reemplaza la dirección de origen del paquete con la dirección de la interfaz LAN, 192.168.1.1. Esto es lo que ve tu Raspberry Pi.
La operación NAT tiene estado, es decir, también mantiene un registro de tabla que dice cuál fue reemplazado por qué y cómo detectar paquetes posteriores de reenvío y respuesta, por lo que los traduce todos correctamente. Sí, resulta que Linux puede hacer DNAT y SNAT al mismo tiempo dentro del mismo flujo.
¿Puedes confiar en este comportamiento? No sé. Si el firmware del enrutador era de código abierto, tuvimos la oportunidad de comprobarlo. Sin fuente, no podemos estar seguros. Este siempre es el caso cuando la fuente está cerrada, es por eso que se deben evitar los productos de fuente cerrada si le preocupa la seguridad.