Las redes privadas también son enrutables
En casa, tengo internet con Ono, y el típico cablemódem-router Hitron (cablemódem + router en un solo aparato). La subred que éste tiene asignada es la 192.168.1.0, con máscara 255.255.255.0. Su IP es 192.168.1.1.
Cuando internet me va lento, hago un ping al router. Si el resultado es bueno (es decir, si la media del round trip time es menor de 1 ms) descarto que mi red sea el problema, y lo achaco a entes externos (ya sea Ono u otros intermediarios). En caso contrario, normalmente el problema es el uso intensivo de la conexión (como P2P) por alguien dentro de mi red.
El caso es que, en lugar de poner ping 192.168.1.1, me equivoqué de tecla, escribiendo 192.168.2.1. Esto es lo que resultó:
[juliet@localhost ~]$ ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=247 time=31.7 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=247 time=31.6 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=248 time=32.0 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=248 time=37.9 ms
^C
--- 192.168.2.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 31.655/33.351/37.940/2.652 ms
¿33 ms de media? Eso es un resultado malo. ¿Qué es lo que ocurre? Entonces caí en el error de la IP. Pero lo chocante no fue eso. Lo sorprendente es que obtuve respuesta ICMP. La única subred de mi casa es 192.168.1.0. Entonces, ¿de dónde sale ese host proveniente de 192.168.2.0? Eso me rompió los esquemas. Probé entonces la herramienta traceroute, que muestra los routers por los que pasamos hasta conectar con el host misterioso:
[juliet@localhost ~]$ traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
1 hitronhub.home (192.168.1.1) 0.707 ms 1.475 ms 1.785 ms
2 * * *
3 * * *
· · · ·
28 * * *
29 * * *
30 * * *
Nada. Lo único que se muestra es el paso por mi router, pero no llega a 192.168.2.1. Esto no podía ser, porque antes había obtenido respuesta ICMP. Entonces se me ocurrió probar con Windows, donde la herramienta se llama tracert:
C:\Users\J>tracert 192.168.2.1
Tracing route to 192.168.2.1 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms hitronhub.home [192.168.1.1]
2 7 ms 5 ms 5 ms 10.144.128.1
3 19 ms 7 ms 6 ms 10.147.240.49
4 31 ms 31 ms 32 ms 10.147.240.153
5 12 ms 11 ms 11 ms 10.254.5.150
6 19 ms 20 ms 22 ms 10.254.3.25
7 25 ms 25 ms 24 ms 10.254.1.230
8 30 ms 25 ms 32 ms 10.167.240.46
9 31 ms 31 ms 31 ms 192.168.2.1
Trace complete.
Bien. Esta vez obtuve respuesta. Al final de este artículo explicaré el porqué de la diferencia entre traceroute y tracert, pero ahora centrémonos en la salida de éste último. Después de salir de mi red, pasa por una serie de routers con dirección privada 10.0.0.0/8. Ya me había fijado en ellos anteriormente, porque también aparecen algunos al hacer un tracert a cualquier dirección de internet. Forman parte de la red interna de Ono, en la que asimismo están los cablemódems. Teniendo en cuenta esto, y viendo el resultado de tracert, es fácil ver que 192.168.2.1 es también un host de Ono.
La razón por la que podemos alcanzar estas redes privadas, sean 10.0.0.0/8, 192.168.0.0/16, o 172.16.0.0/12 si la hubiese, es que las redes privadas también son enrutables. Podemos encontrar una buena explicación en este enlace, donde un usuario se enfrentaba a la misma incógnita que yo:
RE: 192.168.x.x oddities
From: "Burton M. Strauss III" <BStrauss () acm org>
Date: Tue, 15 Jun 2004 11:50:55 -0500
-----Original Message-----
From: Jimmy Brokaw [mailto:hedgie () hedgie com]
Sent: Monday, June 14, 2004 4:49 PM
To: security-basics () securityfocus com
Subject: 192.168.x.x oddities
This seems like a stupid question from a non-guru like me, but I’ve asked
a couple of the «gurus» I know and gotten nothing but strange looks.
I run a small network at home, using a wireless router to connect to a
cable modem. My internal IPs all fall in the 192.168.0.x range, which is
the only address-space the router is configured to support. I’ve got
authentication and logging, so before anyone says «I bet it’s a neighbor
using your connection,» I’ve verified nobody else is logging in.
My understanding is that the entire 192.168.x.x range is for internal
networks only (RFC 1918), and unrouteable on the Internet.
Not true. The RFC 1918 space is not routable on the Global Internet, that
is between ISPs (technically ASNs – Autonomous System Numbers). But it’s
perfectly routable and often is used within an ISP or site.
Resumiendo: no se pueden enrutar direcciones privadas entre ISPs, pero no hay ningún problema en hacerlo dentro del ISP.
Ya que estábamos, también probé a escanear con NMAP:
[root@localhost juliet]# nmap -sn 192.168.2.0/24
Starting Nmap 6.40 ( http://nmap.org ) at 2013-10-04 00:41 CEST
Nmap scan report for 192.168.2.1
Host is up (0.037s latency).
Nmap scan report for 192.168.2.3
Host is up (0.033s latency).
Nmap scan report for 192.168.2.8
Host is up (0.032s latency).
Nmap scan report for 192.168.2.17
Host is up (0.037s latency).
Nmap done: 256 IP addresses (4 hosts up) scanned in 3.46 seconds
NOTA: Sólo me funcionaba como root. Como usuario normal no encontraba nada. En el manual (man traceroute) menciona algo al respecto, aunque no sé si ésa será la razón:
-sn (No port scan) .
The default host discovery done with -sn consists of an ICMP echo
request, TCP SYN to port 443, TCP ACK to port 80, and an ICMP
timestamp request by default. When executed by an unprivileged
user, only SYN packets are sent (using a connect call) to ports 80
and 443 on the target.
Vemos que se detectan 4 hosts, por lo que 192.168.2.1 no es el único. En otras subredes (192.168.0.0/16) hay más.
Como curiosidad, cambié el Hitron a la red 192.168.2.0/24, con IP 192.168.2.1. Como era de esperar, al hacer nmap veía mi propia red, y dejaba de ver los hosts de Ono. Esto es lo correcto: cuando el destino es la red a la que pertenece el router, la entrega es local, no se envía al siguiente router.
Para acabar, vamos a explicar por qué traceroute no mostraba nada y en vambio tracert sí. Resulta que tracert siempre utiliza ICMP, mientras que traceroute emplea por defecto UDP. Seguramente haya algún firewall que lo bloquee. Intenté las opciones -U (UDP con puerto de destino fijo a 53) y -T (TCP), pero tampoco dieron resultado. En cambio, con -I (ICMP) funciona, al igual que Windows:
[root@localhost juliet]# traceroute -I 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
1 hitronhub.home (192.168.1.1) 0.577 ms 1.481 ms 1.873 ms
2 10.144.128.1 (10.144.128.1) 8.047 ms 12.722 ms 13.765 ms
3 10.147.240.49 (10.147.240.49) 13.984 ms 14.130 ms 14.276 ms
4 10.147.240.153 (10.147.240.153) 48.566 ms 48.791 ms 48.936 ms
5 10.254.5.150 (10.254.5.150) 17.923 ms 18.942 ms 19.187 ms
6 10.254.3.25 (10.254.3.25) 24.337 ms 19.783 ms 22.208 ms
7 10.254.1.230 (10.254.1.230) 28.642 ms 27.672 ms 29.546 ms
8 10.167.240.2 (10.167.240.2) 31.003 ms 25.001 ms 10.167.240.46 (10.167.240.46) 36.227 ms
9 192.168.2.1 (192.168.2.1) 37.265 ms 37.456 ms 37.454 ms