¿Qué hace que una dirección IP privada no sea enrutable?

21

Entiendo que las direcciones privadas como 10.0.0.0/8, 172.16.0.0/12y192.168.0.0/16 no son enrutables. Sin embargo, ¿qué es exactamente lo que impide que estas direcciones sean enrutables? ¿Los ISP implementan ACL que impiden el enrutamiento de estas redes o es algo más alto?

Además, ¿es IANA quien creó este diseño?

networking routing ipv4

— QuantumRads
fuente

¿Existe una pregunta implícita de "¿ESTÁ GARANTIZADO que no se enrutarán públicamente, y hay alguien que todavía esté enrutando la acción pública por error?"

— rackandboneman

3

En cuanto a su última pregunta: el IETF los definió para que IANA fuera excluida del espacio público de direcciones. RFC1918 para IPv4 y RFC4193 para IPv6

— Lenniey

3

Por supuesto que son enrutables. Los enrutadores toman un mensaje de su dirección externa pública y lo "enrutan" a una dirección privada interna. Le recomendamos que busque los conceptos básicos de la traducción de direcciones de red

— Lakey

2

Lakey, no son enrutables en la web pública. Por lo tanto, por qué se requiere Nat y se utiliza para conservar las direcciones IP. Estoy en una clase de Cisco y mi profesor no pudo responder a esta pregunta, por eso lo publico aquí.

— QuantumRads

1

Además, debería haber aclarado que las direcciones privadas son enrutables en una red privada pero no en una red pública.

— QuantumRads

39

Las direcciones IP privadas son enrutables, aunque no se enrutan públicamente . Básicamente, un enrutador enrutará una dirección privada a una LAN privada / interna, en lugar de a Internet.

Para ampliar mi respuesta: un enrutador puede enrutar una dirección privada al lado público, a través de su puerta de enlace predeterminada. Sin embargo, el paquete se "perderá" en tránsito debido a que otros enrutadores lo dejarán caer, o debido a que el TTL del paquete llegue a 0.

Por ejemplo, eche un vistazo a esto (parcialmente ofuscado) traceroute -I -n 192.168.200.1:

[root@myhost ~]# traceroute -I -n 192.168.200.1
traceroute to 192.168.200.1 (192.168.200.1), 30 hops max, 60 byte packets
 1  x.x.x.x  0.851 ms  0.841 ms  0.818 ms
 2  6x.xx.xx.xx  0.791 ms  0.791 ms  0.849 ms
 3  15x.xx.xx.xx  1.350 ms  1.347 ms  1.373 ms
 4  15x.x.xx.xx  1.446 ms  1.435 ms  1.428 ms
 5  151.6.68.20  2.272 ms  2.266 ms  2.251 ms
 6  151.6.0.91  8.818 ms  8.256 ms  8.326 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *
...
...
29  * * *
30  * * *

Como puede ver, el paquete se enruta a Internet público a través de la puerta de enlace predeterminada de la máquina. Sin embargo, se deja caer durante el tránsito y nunca llega a ningún destino adecuado.

Después de todo, las IP / clases privadas se superponen (por definición) entre el cliente, entonces, ¿en cuál de las miles de redes 192.168.200.x / 24 se debe enrutar este paquete?

Una nota al margen interesante: los proveedores de internet a menudo usan direcciones privadas para su enrutamiento interno. Si, por ejemplo, un privadas 192.168.200.x / 24 clases se utiliza para el encaminamiento interno, el primer router / máquina con IP 192.168.200.1 será recibir pero descartar el paquete, porque era no solicitado. ICMP es una excepción interesante, ya que los enrutadores / máquinas generalmente responden a PING no solicitados. Esto significa que en algún momento puede usar escaneos de direcciones privadas para mapear su red privada de ISP.

— shodanshok
fuente

2

Básicamente, si la dirección IP comienza con 10, 172.16-31 o 192.168, entonces el enrutador debe configurarse para enviarlos solo a través de la red LAN interna, en lugar de salir a Internet externa (en una empresa, generalmente a través de la red externa puerta). Puede leer sobre estas 'redes privadas' aquí: en.wikipedia.org/wiki/Private_network

— Bruno

3

En realidad, no es raro enrutar direcciones privadas RFC1918 (192.168, 172.16, 10) cada vez que crea una red privada enrutada.

— user253751

3

@Bruno no necesariamente. Una ruta puede enrutar una dirección privada en el lado público a su puerta de enlace predeterminada, pero otros enrutadores finalmente descartarán los paquetes o lo enrutarán en un bucle (y el paquete se descartará cuando su TTL llegue a 0).

— shodanshok

¿Los enrutadores principales del ISP tienen incluso una puerta de enlace predeterminada? ¿Qué podría ser?

— kubanczyk

En general si. Después de todo, un ISP necesita enrutar paquetes destinados a otros ISP ...

— shodanshok

9

Por lo general, el ISP filtra las direcciones IP privadas. Su enrutador de acceso también debe configurarse para que no se filtren.

Las direcciones IP privadas no se pueden usar en Internet porque cualquiera podría estar usándolas . Probablemente hay muchos millones de dispositivos que utilizan 192.168.1.1 de forma privada, ¿cuál se supone que un enrutador de Internet envía el paquete?

Las direcciones de Zeroconf (169.254.0.0/16) en realidad no son enrutables. Se pueden usar en cualquier lugar de manera ad-hoc, pero no pueden acceder a Internet ni a ninguna subred que no sea la local. No se pueden enrutar porque solo pueden ser válidos dentro del dominio de difusión donde cada dispositivo puede seleccionar una dirección no utilizada por sí mismo. Por definición, zeroconf no tiene una instancia de administración como un servidor DHCP.

— Zac67
fuente

6

Sin embargo, ¿qué es lo que impide que estas direcciones sean enrutables?

Estándares aceptados que se hacen cumplir por las entidades que se comunican. Estos se aplican en software, hardware y configuraciones.

¿Los ISP implementan ACL que impiden el enrutamiento de estas redes o es algo más alto?

Pueden hacerlo, pero lo que realmente se está deteniendo es simplemente una traducción no válida que no sigue los estándares.

Si usted es como la mayoría de los usuarios domésticos, tiene una dirección IP asignada como dirección IP pública. Para que el tráfico de todos sus dispositivos conectados se comunique, el enrutador realiza la traducción de esas direcciones IP internas mediante NAT (traducción de direcciones de red) o PAT (traducción de direcciones de puerto).

Básicamente, su enrutador recuerda qué direcciones IP internas en su LAN (red de área local) iniciaron una sesión que se extendía fuera de su LAN, a través del enrutador y fuera de la interfaz WAN (red de área amplia). Cuando los datos salen del enrutador, contienen esa única dirección IP asignada a usted como la IP de origen. Cuando ingresa, el paquete contiene la misma dirección que la IP de destino. El enrutador decide entonces a dónde se dirige desde allí.

En el exterior, solo tiene una única dirección IP, que en realidad es la IP del enrutador. El enrutador puede rastrear esas sesiones y determinar qué tráfico pertenece a cada dirección IP interna en su LAN y dirige ese tráfico en consecuencia. Es un proceso de administración complejo, pero la idea es bastante simple una vez que comprende que todo se está traduciendo en cada enrutador.

Además, la mayoría de los enrutadores domésticos tienen puertos de conmutación, por lo que el tráfico se entrega a través de la dirección MAC, no de la dirección IP. La dirección MAC de origen en el paquete permanece igual hasta que llega a un enrutador. El enrutador elimina esa dirección MAC de origen e inserta la dirección MAC de su propia interfaz WAN.

Además, ¿es IANA quien creó este diseño?

Estos estándares no fueron diseñados originalmente por IANA. Hoy, aunque toman la iniciativa de establecer estándares, ciertamente no los hacen cumplir por ningún medio legal. Son estándares que se hacen cumplir por consenso. Buscar RFC 791.

Tienen "autoridad" en la medida en que todos estén dispuestos a adherirse a ellos. Es completamente posible desafiar estos estándares, pero eventualmente se encontrará con un ISP en algún lugar a lo largo del camino que le exigirá que se adhiera o dejarán caer su tráfico.

Espero que eso ayude..

— CipherBytes
fuente

2

Creo que cada palabra de esto da en el clavo, en lo que respecta a la pregunta específica del OP. Las otras respuestas son objetivamente correctas, pero no estoy seguro de que aborden la confusión específica del OP tan directamente como puedan. El punto clave es: la convención y el hecho de que la mayoría de la gente quiere cumplirla .

— Lightness compite con Monica

1

@LightnessRacesinOrbit: Eso está cubierto básicamente por la primera palabra no citada en esta respuesta, lo que no sería estrictamente necesario ... La palabra enfatiza el punto que usted hace. Sin embargo, estoy de acuerdo en que su texto en cursiva mejora el punto.

— TOOGAM

2

@TOOGAM: Sí, solo lo estoy informando nuevamente. Como dije, creo que esta respuesta es perfecta.

— Lightness compite con Monica

1

Como punto de aclaración de las otras respuestas, los rangos de direcciones IP privadas que está utilizando localmente no se dirigen a Internet porque tienen sus propias entradas explícitas en la tabla de enrutamiento. Aquí está mi tabla de rutas desde mi escritorio en casa, por ejemplo:

$ ip route
default via 192.168.1.1 dev enp5s0 proto dhcp src 192.168.1.104 metric 1024 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.18.0.0/16 dev br-90a372f4b373 proto kernel scope link src 172.18.0.1 linkdown 
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.104 
192.168.1.1 dev enp5s0 proto dhcp scope link src 192.168.1.104 metric 1024

Tenga en cuenta la 172.17.0.0/16y 172.18.0.0/16. Los paquetes a estas redes irán directamente a mis puentes acoplables, sin salir de mi computadora, porque tienen una entrada específica en mi tabla de rutas. La 192.168.1.0/24entrada dice explícitamente que el tráfico a esa red saldrá delenp5s0 interfaz. La tabla de rutas de mi enrutador tendrá una entrada similar que enviará todo el tráfico de esa red privada a la interfaz a la que está conectado mi escritorio.

Solo los paquetes para redes que no están explícitamente en la tabla irán a la ruta predeterminada. Puede marcar explícitamente una red como inalcanzable mediante:

$ ip route add unreachable 10.0.0.0/8

Esto cambia mi tabla de ruta a:

$ ip route
default via 192.168.1.1 dev enp5s0 proto dhcp src 192.168.1.104 metric 1024 
unreachable 10.0.0.0/8 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.18.0.0/16 dev br-90a372f4b373 proto kernel scope link src 172.18.0.1 linkdown 
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.104 
192.168.1.1 dev enp5s0 proto dhcp scope link src 192.168.1.104 metric 1024

Ahora, mi escritorio ni siquiera intentará preguntarle a la puerta de enlace predeterminada sobre las direcciones en ese rango. Las búsquedas de esa dirección devuelven inmediatamente "No hay ruta al host".

$ traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 60 byte packets
connect: No route to host

Los paquetes para redes inalcanzables que no están marcados explícitamente como inalcanzables en la tabla de rutas simplemente se seguirán enviando a través de las rutas predeterminadas, hasta que el paquete llegue a un enrutador que sepa explícitamente que la red es inalcanzable, o el TTL caduca.

— Karl Bielefeldt
fuente