¿ Pueden existir IP privadas en internet ?
Fecha: 8 de junio del
2023
Escenario
Aquí se analiza por qué a veces aparecen IP
privadas en una traza que llega desde internet y si eso es “legal” (en términos
técnicos).
1.- Que esconden a veces los
ISP:
La respuesta es no esconden nada, simplemente se
ahorran direcciones IP públicas (acorde con la RFC 1918)
ya que escasean (como los
dolares aquí en
Argentina) en segmentos de “backstage” o de interconectividad no visibles o
alcanzables para usuarios que deban utilizar
servicios en internet (host finales).
Para esto nos referimos a que
si las comunicaciones son de extremo a extremo, deberían ser de IP pública a IP
pública, sin importar lo que
suceda en el medio, que como en este caso,
utilizan direcciones IP privadas.
Cuando se interconectan redes de segmentos
público, se anuncian a través de BGP, que es el protocolo estándar para todos
en internet y
que hace alcanzable dicho segmento desde
cualquier lugar (de internet), pero que algunas veces se redistribuyen en routers que manejan
tanto BGP como algún protocolo IGP que podría ser
EIGRP u OSPF, que es interno de cada ISP dentro de su sistema autónomo (AS)
hasta
llegar a algún router
de borde del AS que vuelve a redistribuirlo en BGP.
Esos segmentos IGP pueden manejar direcciones IP privadas
(10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/24) para intercambiar rutas dentro
del AS, siendo filtradas (generalmente) por los
mecanismos de redistribución de los routers eBGP (external BGP o de
intercambio entre AS
de diferentes ISP, o también ISP-cliente final
que maneje BGP por ejemplo. Esto hace “invisible” a
esos segmentos con IP privadas, pero
en ocasiones salen a la luz, como en un trace.
Cuando realizamos un trace a un destino,
generamos tráfico con un TTL 1 y vamos aumentándole el valor a medida que nos
alejamos de
nuestra red. Cada vez que un router
recibe un paquete con TTL 1 nos debe matar el paquete y avisarnos mediante ICMP
tiempo expirado
en tránsito (time exceeded),
estos mensajes provienen desde la IP más cercana a nuestro origen, según su
tabla de enrutamiento.
Si esta IP más cercana es una IP privada, el router generará el mensaje ICMP con dicha IP,
independientemente si es privada o pública,
cada router intermedio
que reciba y reenvíe ese mensaje hasta nosotros, solo mirará el destino
(nuestra IP pública) sin mirar el origen.
Por lo tanto ese mensaje
llegará a nosotros con una IP que sea privada o no.
Puede suceder que nuestro equipo de borde sea un
firewall y este tenga reglas anti-spoofing
(RFC 1918 compliant), que dicen que si desde
internet llega algo con 10.x.x.x, 172.16.x.x/12 o
192.168.x.x se deberá descartar, porque siempre deberían ser IP públicas. En
esos casos en
el trace veremos los saltos como * * * Request timed out , que aunque el
mensaje llegó, el firewall lo mata por las dudas que sea un intento
de spoofing, esto es,
alguien de afuera que se hace pasar por alguien de adentro.
También a veces esos saltos con * * * pueden ser
equipos a los que no les interesa avisar que nos mataron el paquete, o que sólo
sepan llegar
al destino y no como llegar a nuestro origen
(visto como su destino). Cada caso es un caso de estudio.
¿Qué pasa con el tráfico que llega desde una VPN
L2L? lo deja pasar, porque viene encapsulado dentro de un paquete ESP o el
método que
sea, con la dirección IP pública de nuestro peer
VPN, y al desencapsularlo (quitar la cabecera IP que
se utilizó para viajar por internet) quedará
el paquete original con las IP privadas de origen
y destino.
2.- Un trace real:
Aquí podemos ver un ejemplo real de un trace
realizado desde mi conexión a internet con una IP pública.
C:\>tracert
www.cisco.com
Tracing route to e2867.dsca.akamaiedge.net [23.197.234.230]
over a maximum of 30 hops:
1 3 ms
3 ms 2 ms dsldevice.lan
[192.168.1.254] (mi router de internet)
2 8 ms
8 ms 9 ms 100.124.41.2
3 9 ms
* 12 ms 10.0.3.232 (la IP privada en cuestión)
4 23
ms 19 ms 13 ms be5-2.cf223-br-05.claro.net.ar
[170.51.254.176]
5 44 ms 48 ms 50 ms
host165.170-51-254.telmex.net.ar [170.51.254.165]
6 *
* * Request timed out. (probablemente sean routers a los que no les interesa avisar)
7
* * *
Request timed out.
8 18 ms 17 ms 21 ms
a23-197-234-230.deploy.static.akamaitechnologies.com [23.197.234.230]
Trace complete.
C:\>ping 100.124.41.2 (verificamos llegar al segundo
salto)
Pinging 100.124.41.2 with 32 bytes of data:
Reply from 100.124.41.2: bytes=32 time=5ms TTL=254
Reply from 100.124.41.2: bytes=32 time=13ms TTL=254
Reply from 100.124.41.2: bytes=32 time=9ms TTL=254
C:\>ping 10.0.3.232 (verificamos llegar al tercer
salto con la IP privada)
Pinging 10.0.3.232 with 32 bytes of data:
Request timed out. (es correcto, un router de internet no debería saber llegar)
Request timed out.
Request timed out.
Request timed out.
C:\>ping 170.51.254.172 (verificamos llegar al cuarto
salto)
Pinging 170.51.254.172 with 32 bytes of data:
Reply from 170.51.254.172: bytes=32 time=23ms TTL=251
Reply from 170.51.254.172: bytes=32 time=19ms TTL=251
Reply from 170.51.254.172: bytes=32 time=23ms TTL=251
Reply from 170.51.254.172: bytes=32 time=19ms TTL=251
3.- Otro ejemplo de
utilización de IP privadas:
Aquí podemos ver que un ISP está publicando
segmentos del rango 172.16.x.x/12 (privadas de clase B que abarcan hasta la
172.31.x.x) y donde probablemente haya un
mecanismo de redistribución mal ajustado (no se discutirá aquí).
3.1.- En la tabla de
enrutamiento:
rt-inet-telecom#sh ip route | beg 172.16.0.0/16
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
B 172.16.144.0/22 [20/0] via
186.108.25.65, 3d02h
B
172.16.160.0/20 [20/0] via 186.108.25.65,
3d02h
B
172.16.176.0/20 [20/0] via 186.108.25.65,
3d02h
B 172.16.192.0/20
[20/0] via 186.108.25.65, 3d02h
B
172.16.208.0/20 [20/0] via 186.108.25.65,
3d02h
172.18.0.0/19 is subnetted,
4 subnets
B 172.18.128.0 [20/0] via
186.108.25.65, 3d02h
B
172.18.160.0 [20/0] via 186.108.25.65, 3d02h
B
172.18.192.0 [20/0] via 186.108.25.65, 3d02h
B 172.18.224.0 [20/0] via
186.108.25.65, 3d02h
172.19.0.0/19 is subnetted, 1 subnets
B 172.19.0.0 [20/0] via
186.108.25.65, 3d02h
B 172.32.0.0/11 [20/0] via 190.225.250.31, 12:32:07 (esta ya no es del rango privado
clase B)
3.2.- En la tabla BGP:
rt-inet- telecom #sh ip bgp | beg 172.16.144.0
* i 172.16.144.0/22 200.0.0.1 0
100 0 7303 7303 I (aquí podemos ver que son propios
del AS 7303)
*> 186.108.25.65 0 7303 7303 i
* i
172.16.160.0/20
200.0.0.1 0 100
0 7303 7303 i
*> 186.108.25.65 0 7303 7303 i
* i
172.16.176.0/20
200.0.0.1 0
100 0 7303 7303 i
*> 186.108.25.65 0 7303 7303 i
* i
172.16.192.0/20
200.0.0.1 0 100
0 7303 7303 i
*> 186.108.25.65 0 7303 7303 i
* i
172.16.208.0/20
200.0.0.1 0 100
0 7303 7303 i
*> 186.108.25.65 0 7303 7303 i
* i
172.18.128.0/19
200.0.0.1 0 100
0 7303 7303 i
*> 186.108.25.65 0 7303 7303 i
* i
172.18.160.0/19
200.0.0.1 0 100
0 7303 7303 i
*> 186.108.25.65 0 7303 7303 i
* i
172.18.192.0/19
200.0.0.1 0 100
0 7303 7303 i
*> 186.108.25.65 0 7303 7303 i
* i
172.18.224.0/19
200.0.0.1 0 100
0 7303 7303 i
*> 186.108.25.65 0 7303 7303 i
* i
172.19.0.0/19
200.0.0.1 0 100
0 7303 7303 i
*> 186.108.25.65 0 7303 7303 i
*> 172.32.0.0/11 190.225.250.31 0 7303 7303 6762 6461 21928 i
* 190.0.0.2 2553 0 3549 3549 3549 3356 6461
21928 i
rt-inet- telecom #
3.- En una página de
consultas BGP:
Fuente: https://bgp.he.net/ y https://bgp.he.net/AS7303#_prefixes
(2023) Perfect strangers
Rosario,
Argentina