Haciendo el marciano con las redes @ Samquejo | 2022-01-31T08:00:01+01:00 | 9 minutos de lectura | Actualizado en 2022-01-31T08:00:01+01:00

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.

Red Inicio Fin Tamaño
10/8 10.0.0.0 10.255.255.255 16777214
172.16/12 172.16.0.0 172.31.255.255 1048574
192.168/16 192.168.0.0 192.168.255.255 65534

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.

Protocolo Red Inicio Fin Tamaño Descripción Fuente
IPV4 10/8 10.0.0.0 10.255.255.255 16777214 Habitualmente, red local grande rfc1918
IPV4 172.16/12 172.16.0.0 172.31.255.255 1048574 Habitualmente, red local mediana rfc1918
IPV4 192.168/16 192.168.0.0 192.168.255.255 65534 Habitualmente, red local pequeña rfc1918
IPV4 169.254/16 169.254.0.0 169.254.255.255 16777214 APIPA. Direccionamiento de autoconfiguración y enlace local rfc1918
IPV4 127/8 127.0.0.0 127.255.255.255 16777214 Loopback. Direccionamiento de bucle invertido rfc1918
IPV4 0/8 0.0.0.0 0.255.255.255 16777214 Red propia. Es algo que sé que se usa, pero que nunca he usado a posta más allá de indicar que 0.0.0.0 es todos los adaptadores rfc1918
IPV4 224/4 224.0.0.0 239.255.255.255 268435454 Multicast. Hay muchos subrangos específicos por tipología rfc1918
IPV4 240/4 240.0.0.0 255.255.255.254 268435454 Uso reservado por IANA. De momento no se usan oficialmente rfc1918
IPV4 255.255.255.255/32 255.255.255.255 255.255.255.255 1 La última IP. Broadcast limitado principalmente usada como destino de anuncio de broadcast. En teoría es parte del segmento anterior rfc1918
IPV6 fc00::/7 fc00:: fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff Mucho más que enorme Rango ULA. Son las direcciones locales únicas rfc4193
IPV6 fe80::/10 fe80:: febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff Enorme Rango de enlace local unicast rfc4291
IPV6 fec0::/10 fec0:: feff:ffff:ffff:ffff:ffff:ffff:ffff:ffff Enorme Rango de enlace local unicast, ya fuera de uso rfc3879
IPV6 ff00::/8 ff00:: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff Más que enorme Multicast. La mitad es local y la mitad, a partir de ff0e:/16 es global y puede salir a internet rfc4291
IPV6 ::ffff:0:0/128 ::ffff:0000:0000 ::ffff:0000:0000 1 Pertenece a la red ::ffff:0:0 donde es posible mapear direcciones IPv4 en estado 1:1 rfc4291
IPV6 ::/96 :: ::ffff:ffff Todo IPv4 Red con mapeo directo a todo el rango IPv4 rfc4291
Tamaño Cantidad Base 2 Base 10
Todo IPv4 4294967296 2^32 4.294967296 x 10^9
Enorme 332306998946228968225951765070086144 2^118 3.323069989462289 × 10^35
Más que enorme 1329227995784915872903807060280344576 2^120 1.329227995784916 × 10^36
Mucho más que enorme 2658455991569831745807614120560689152 2^121 2.6584559915698317 × 10^36

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.

Protocolo Red Descripción
IPv4 100.64.0.0/10 Carrier-grade NAT/CG-NAT rfc6598
IPv4 192.0.2.0/24 TEST-NET-1 rfc5737
IPv4 198.51.100.0/24 TEST-NET-2 rfc5737
IPv4 203.0.113.0/24 TEST-NET-3 rfc5737
IPv4 198.18.0.0/15 Reserved by IETF (For use in benchmark tests of network interconnect devices) rfc2544
IPv6 2001:db8::/32 Documentation prefix rfc3849
IPv6 2000::/7 IPv6 Additional Bogon Ranges que incluye la documentación y mapean rangos IPv4 con 6to4 y teredo

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

© 2019 - 2024 YoVirtualizador

Powered by Hugo with theme Dream.

avatar

El blog de YoVirtualizadorTu podcast y blog de confianza

Acerca de YoVirtualizador

YoVirtualizador es la marca de varios proyectos

Podcast de informática profesional. Canal de Youtube sobre el blog, el podcast y de temática profesional. Blog de contenido diverso, con temática BOFH y técnica.

Gracias por la lectura.

Política de comentarios

En YoVirtualizador todos los comentarios serán bienvenidos pero moderados.

Respetos guardan respetos.

El contenido irrelevante u ofensivo será eliminado.

Galletas

Política de cookies

En YoVirtualizador no usamos cookies para nada, pero los servicios de discus y analytics recopilan datos en servidores ajenos a YoVirtualizador sin que yo pueda hacer nada.

Este aviso es sólo porque algún político tenía que justificar su existencia.

Si hace clic en un enlace de afiliado y compra un producto o servicio, es posible que ese comerciante nos pague una tarifa.