Una IP privada no existe fuera de su red

El montaje ya era el temario

Monté un laboratorio de dos máquinas. Resuelves la primera y desde ahí tienes que pivotar a la segunda, que no se ve desde fuera. Para que eso pueda pasar puse las dos en una red NAT de VirtualBox.

Hace poco preguntaron en un canal por qué no arrancaba. Las máquinas del laboratorio en VirtualBox con la red NAT que indica el PDF, y el Kali atacante en VMware con esa misma red NAT creada igual. Mismo nombre, mismo rango, las dos en NAT. Y nada.

Fui a descargar el laboratorio para probarlo yo y la descarga me falló, así que me tocó explicarlo de memoria. Al explicarlo me di cuenta de que el fallo estaba en mi PDF.

Una red NAT es una isla

Cuando pones una máquina en NAT, el hipervisor no la enchufa a tu red. Levanta un switch virtual con su propio driver de kernel y cuelga la máquina de ahí dentro. VirtualBox llama al suyo vboxnet. VMware llama al suyo vmnet. Dos islas, cada una dentro de su programa, sin nada que las una.

La máquina recibe una IP del estilo 10.0.2.15 o 172.16.83.128, y ese número solo significa algo dentro de su isla. Fuera de ahí no le dice nada a nadie.

Yo también daba por hecho que era 10.x

Escribiendo esto me di cuenta de que arrastraba un vicio. Como VirtualBox por defecto me saca una 10.0.2.x, tenía metido que una red NAT es 10.x y ya está. Fui a mirar la de VMware en mi propio equipo y me encontré una 172.16.83.0/24 que ni había elegido yo ni había visto nunca.

Y hay algo peor. En el PDF que acompaña a mi laboratorio, en la misma captura donde señalo con una flecha roja la red que hay que crear, se ve justo debajo otra red NAT de VirtualBox en 192.168.50.0/24. Lo tenía delante desde el primer día.

No hay ninguna regla que diga 10.x. Cuando se repartió IPv4 en 1981 se hizo por clases, según con qué número empieza la dirección. En 1996 la RFC 1918 apartó un bloque de cada clase para uso interno.

Privadas quiere decir que ningún router de internet las encamina. Un paquete con ese destino se tira en cuanto sale a la red pública, y por eso las mismas direcciones están repetidas en millones de casas sin que choquen.

Los tres bloques valen igual para montar una red NAT y cada hipervisor coge el que quiere. El 192.168.1.1 del router de casa es el de clase C, el que todo el mundo reconoce.

Por qué el host sí las ve

Aquí está la parte que confunde. Desde el host llegas a las dos máquinas, y eso hace pensar que si el host las ve, ellas se verán entre sí.

El host es el punto en común porque es quien levanta las dos redes. Cada red NAT tiene una puerta de enlace, y esa puerta es un dispositivo que corre en el propio host. Tiene un pie en cada isla.

Se ve en la configuración, no hace falta creérselo. En mi equipo, dentro de la red de VMware el host responde en la 172.16.83.1 y la puerta de enlace que da salida es la 172.16.83.2. Esas dos direcciones están en la misma máquina en la que VirtualBox monta su 10.0.2.0/24 por otro lado.

Llegas a las dos porque las dos nacieron dentro de él. Lo que no existe es un camino de una isla a la otra.

Por qué entre ellas no

Las dos máquinas están en switches distintos, sin ningún cable entre medias. Cuando la de VirtualBox manda un paquete a 172.16.83.128, esa dirección no existe en su isla. El paquete sale hacia su puerta de enlace, el motor NAT lo traduce hacia fuera, hacia tu red física o internet, y ahí muere. Nadie fuera sabe cómo volver a una IP privada escondida detrás de otro NAT.

NAT es una puerta de un solo sentido. Desde dentro sales. Desde fuera no entra nadie. Dos NAT son dos puertas mirando hacia fuera, y nadie cruza de una habitación a la otra.

Y aquí está la trampa. Puedes crear en VMware una red NAT con el mismo nombre y el mismo rango que la de VirtualBox, y sobre el papel tendrás las dos máquinas en la misma red. Por dentro siguen siendo dos switches que no se conocen de nada. El nombre y la IP son etiquetas que cada programa entiende puertas adentro, y copiar la etiqueta no tiende ningún cable.

Bridged es la excepción

Si en lugar de NAT usas modo puente, la máquina deja de estar en una isla. Cuelga de tu red física, coge una IP de tu router y pasa a ser un dispositivo más de tu LAN. Dos máquinas en puente se ven aunque estén en hipervisores distintos, porque están las dos en la red de tu casa. Por eso el consejo de ponerlo todo en puente a veces funciona.

Lo que pasa es que mi laboratorio no quiere eso. Si todo cuelga de tu LAN plana, las dos máquinas quedan accesibles desde el principio y no hay nada que pivotar. Esa NAT es justo lo que construye la topología del ejercicio.

O sea que la pelea con el adaptador de red ya era el ejercicio, disfrazado de problema de instalación. Pivoting es enrutar tráfico a través de una máquina para llegar a un segmento que no ves, y eso son redes puras y duras, sin ninguna asignatura aparte.

Y el PDF que va con el laboratorio son dos capturas con flechas rojas. Dónde pulsar y qué prefijo escribir. En ningún sitio pongo por qué hace falta esa red, ni que la máquina atacante tiene que estar en el mismo VirtualBox. Enseñé el clic y me salté el concepto.

Si te pasa a ti

Antes de tocar nada más, monta una máquina cualquiera, un Ubuntu server vale, ponle el mismo adaptador NAT que al laboratorio y hazle ping. Si responde, el problema no está en la red. Si no responde, ya sabes que estás peleándote con el montaje y no con el reto.

Treinta segundos de comprobación y te ahorras la tarde. Ahí está.