Haciendo el marciano con las redes

Queda documentado por múltiples grupos de telegram, y seguramente en otros sitios como reddit o quizás también ¿facebook? ¿foros?… Mis sitios y algunos que ya nadie usa, que un usuario normal no lee documentación, y cuando la lee, no entiende lo que pone.
Entre el gremio técnico, la cosa tampoco es esperanzadora.
Y mis esperanzas, entre frikis andaba el juego, también me llevo cada chasco…

Bueno, pero ¿y por qué es hacer el marciano?

Realmente es un juego de palabras sobre el concepto de los martians, también llamados bogons.

Para entender donde voy, vamos con un poco de base de conocimiento. El conocimiento no hace daño salvo que se te caiga encima la enciclopedia desde la estantería.

Redes locales

Lo más habitual es encontrarse con 3 grupos de direccionamiento para redes locales. Estaréis cansados de verlas.

Esto es al menos lo que dice el RFC1918 o mejor aún, su traducción.

De ahí, si no hacemos cosas raras, y no nos salimos, no debería haber problemas, como los que he comentado al principio.

Eso es lo habitual, y lo es en ipv4.
Lo bueno es que también lo tenemos en ipv6, pero como no hay una interrelación directa, necesito ampliar la tabla anterior, y como lo de las RFC me empieza a sonar a marciano, tiro de los hilos de @wearedementors donde explica de una forma ideal otras cosas y me quedo con la base de los cálculos. Gracias @fckinsanity.

Que si, que todo esto ya lo sabemos. ¿A donde quieres llegar?

Pues muy simple.
Hay otros rangos llamados Bogons, o Martians, de ahí lo del marciano y no es por referencia al rango de IP asignado a la operadora que se establezca en la luna o marte, que representan unos tipos especiales de uso, por ejemplo los de documentación, o de test, o de lo que sea que queramos, no productivo, o si pero con unas características y limitaciones muy especiales.

Obviamente hay alguno más, pero que no me queda claro su uso actual, ni si quiera si está en uso, y me quiero centrar en esto porque es donde he visto que la mayoría de los usuarios sin conocimientos (o lo que es peor, con ellos y sin ganas de leer y entender) fallan a la hora de interpretar una documentación.

Ejemplo número 1

En este primer caso de estudio encontramos la documentación de un producto de HP (actualmente propiedad de Microfocus) donde se hace referencia la la instalación de un servidor periférico en una red remota.
Todo iría bien si en el esquema de la documentación, quien redactó el manual de operación personalizado a cada instalación, un día hablaré de los entregables que solíamos hacer, no hubiera sido copiado de la web de HP, con un esquema dibujado con las IP de documentación de TEST-NET-1 en lugar de poner las reales de la instalación, cosa que aparecía en el documento de implantación, en una tabla bien diseñada.
Y es que claro, eso de leer…

Ejemplos 2 y 3

Quería mantenerlos separados porque son de dos fuentes diferentes pero es que es lo mismo.
Ya sea por telegram o por correo, me han llegado dos veces lo mismo. Pantallazos de instalación de diversos productos que por defecto traen unas IP que el fabricante indica que se deben cambiar.
No quiero entrar a hacer sangre sobre si el fabricante del aplicativo debería forzar más a los usuarios a cambiar las IP, por ejemplo con más validaciones o con campos con máscaras de entrada más estrictas, o incluso avisos y leyendas…. En fin, que tampoco es que los fabricantes ayuden.

El caso es que diseñar una interfaz de VPN de OpenVPN o de Wireguard y poner 198.18.0.1/24 como gateway y red para los clientes no es infrecuente, así como no lo es que venga alguno preguntando por qué no conectan luego.
Los que habitualmente han esquivado esa bala es porque han modificado dicha configuración, sea porque las IP no les gusten, porque tengan otras que se saben y por que no desentone, o porque lo leen de un manual que alguien ha redactado y que no ha explicado este tema, pero gracias a eso, funciona.

Pues eso, que la red 198.18.0.0/15 como pone la tabla está pensada para otra cosa, y por eso es lógico que lo tire el cortafuegos.
Actualmente está anunciada como documentación, pero debería ser la de test de velocidad o carga o lo que quiera que sea que tengan pensado con esa descripción.

Contraejemplo adicional

Tengo también 2 ejemplos más de dos fabricantes, que no se si es que hicieron piña común cuando hicieron la documentación o que pasó con sus documentos de formación.

El primero de ellos es con la propia HP, ahora HPE, que ha conservado parte de sus direcciones IP originales de cuando se distribuyó y repartió la primera baraja.
Pues eso, que como dentro de unos de sus /8 hay huecos de direcciones, había unos cuantos /24 que usábamos para documentación, laboratorios… lo que fuera.
Ni que decir tiene que no salían a internet, pero bueno, tenían pinta de ser ips públicas y ya.

El segundo es Vmware, donde en su documentación de NSX solía (hasta la versión 6.4 al menos, después ya no sé) poner direcciones IP random como ejemplos para la construcción de sus mallas OSPF o BGP, cosa que con los bogons hubiera quedado un poco menos “feo” el tema.
sarcasmo Por suerte no conozco ningún caso de alguien que tenga 1.1.1.1 como parte de su implementación de red. sarcasmo desactivado
Lo que sí se usa, y tiene lógica, son direcciones APIPA en los NSX-edge para su heart-beat.

Nota para este blog, videos y el podcast

Bueno, pues es muy simple.
Ahora que ya conocéis que son los bogons, el chiste del principio queda definido en la rfc 1812 y habla de los martians, los paquetes marcianos, en un juego de palabras que no da para mucho más.
Lo que debe quedar claro, es que esos martians packets serán descartados en cualquier firewall salvo que el se le indique lo contrario.
Por ejemplo si yo configuro un enrutamiento entre una red 198.18.0.0/15 y la 192.0.2.0/24 y además hago que tenga como core 203.0.113.0/24 puedo obtener una traza interesante, que parezca que va todo por ip públicas, que queda bonito y más llamativo que enseñar las clásicas 192 de turno… Pero claro, eso ha tenido un coste.
En producción, yo no soy un proveedor de servicios de red, ni un carrier, y como mucho tendré mi puñado de IP públicas en la wan de mis dispositivos así que voy a realizar el enrutamiento interno entre mis segmentos de red con lo más diverso de lo más diverso, y esa diversidad suele acabar convertida en firewalls de capa 4. La diferencia entre un switch de capa 3 o un router, y los firewalls, es que en el firewall voy a definir zonas entre las que está permitido o no el tránsito de paquetes, y ahí es donde entran las limitaciones, que también tienen algunos routers. Por defecto, no se permiten reglas que tengan en ambos miembros, una dirección de los rangos definidos en la rfc 1918, o bien los definidos por la rfc 1812.

Esto tiene una lógica, un sentido, que viene de hace tiempo.
Y es que si pongo un firewall, lo más habitual es que lo ponga como seguridad perimetral.
Eso hace que de normal, el firewall espere en uno de los miembros una IP “normal” y en el otro, una local.

Pues eso, que si en algún momento me veis manejando direcciones de las que he comentado en este artículo, ya sabéis de que va la historia, y lo que significa cada cosa.

Y un ejemplo son los artículos que hice sobre iperf

YoVirtualizador en formato podcast. Ahora también en Sospechosos Habituales: https://feedpress.me/sospechososhabituales
Sin más, os dejo los enlaces:

Web: https://www.yovirtualizador.com
Grupo de telegram: https://t.me/grupovirtualizador
Podcast: https://www.ivoox.com/podcast-yovirtualizador_fg_f1563806_filtro_1.xml
Canal de youtube: https://www.youtube.com/channel/UC0R70cABSsmC6TFyXth0qPg
Enlace de afiliados de amazon: https://amzn.to/3gX3HmK
Enlace de referidos de la Asociación Podcast: https://www.asociacionpodcast.es/registrarse/socio/?coupon=SB6A70