Cómo comprobar rutas BGP y la validez RPKI
Una comprobación de rutas BGP responde a una pregunta que una comprobación del servidor no puede: no «¿está la máquina en pie?», sino «¿está internet transportando de verdad el tráfico hacia este prefijo, y desde el origen correcto?». Lee los anuncios que ven las demás redes — el sistema autónomo de origen, las rutas AS, cuántos colectores de rutas ven el prefijo en absoluto — y los contrasta con RPKI, el registro firmado de quién puede originar qué. Esta guía recorre qué significa cada señal, dónde engaña, y una rutina de cinco pasos con la consulta BGP de este sitio.
Última actualización:
Cuando las rutas salen mal
El escenario es familiar para quien haya operado un servicio público: el sitio carga para ti, el servidor está sano, el certificado es válido — y los clientes de otro país no obtienen nada. La monitorización desde tu propia oficina dice que todo va bien. Su tráfico nunca llega, porque la alcanzabilidad no es una propiedad de tu servidor. Es una propiedad de los anuncios que transportan tu prefijo a través de las redes de otros, y esos anuncios pueden cambiar, ser filtrados o ser contradichos sin que nada en tu máquina cambie en absoluto. «El sitio está caído» es a veces un hecho de enrutamiento con disfraz de servidor.
Los fallos de ruta tienen tres formas que conviene distinguir. Un secuestro: otro sistema autónomo anuncia tu prefijo — o un trozo más específico de él — y atrae tráfico que nunca fue suyo. Una fuga de rutas: una red propaga rutas que recibió a pares o proveedores a los que no debería habérselas enviado, de modo que el tráfico da rodeos absurdos o cae en una red que no puede entregarlo. Y la silenciosa: un anuncio retirado o filtrado por un cambio de configuración, una disputa de peering o un descarte RPKI, de modo que parte de internet simplemente se queda sin camino. Las soluciones para las tres son totalmente distintas, y por eso el primer trabajo es distinguirlas — y eso empieza mirando qué se anuncia realmente.
Empieza por el anuncio
La primera pregunta es la más sencilla: ¿se anuncia este prefijo a la tabla global en absoluto y, si es así, quién lo hace? El último AS del anuncio — el ASN de origen — nombra la red que dice poseer el prefijo, y los datos de registro tras él nombran la organización a la que pertenece ese ASN. Si el origen es tu propio ASN, o el de tu proveedor, el anuncio al menos reclama el hogar correcto. Si es un nombre que nunca has visto, has aprendido algo importante en los primeros diez segundos.
Los casos límite contienen la información. Un prefijo sin ningún origen no se está anunciando en ningún sitio que los colectores puedan ver — una errata en el prefijo, un anuncio nunca hecho, o uno retirado en todas partes; comprueba si hay un prefijo menos específico que lo cubra antes de concluir nada, porque el tráfico puede seguir fluyendo bajo el agregado. Varios orígenes para un mismo prefijo no son automáticamente sospechosos: los servicios anycast y los grandes CDN originan el mismo prefijo desde muchas redes por diseño, y un prefijo a mitad de transferencia entre proveedores puede mostrar dos orígenes legítimamente durante un tiempo. Varios orígenes más un titular que no reconoces, empezando en un momento en que tú no cambiaste nada: esa es la combinación que merece alarma.
Visibilidad y rutas AS
Un looking glass no pregunta a tu router; pregunta a los colectores de rutas — los colectores RIPE RIS detrás de los datos de este sitio hacen peering con redes de todo el mundo y registran lo que esos pares les anuncian. La visibilidad es el recuento de pares de colectores que ven tu prefijo en absoluto. Un prefijo sano y veterano suele ser visto por casi todos. Un recuento en caída libre — o uno que ayer estaba completo y hoy es un puñado — sugiere un anuncio que se está retirando, filtrando, o que solo se ve a través de un conjunto de caminos que se estrecha.
La ruta AS es la cadena de redes que un anuncio ha recorrido: léela de derecha a izquierda, desde el origen hacia fuera a través de los proveedores de tránsito hasta el par del colector. Te dice qué upstreams transportan la ruta y dónde se sienta tu propio proveedor en la cadena — y cuando ocurre una fuga, la ruta muestra la red que no debería estar ahí, en el medio, reenviando el tráfico de lado. Un hábito de lectura que conviene adquirir: un ASN repetido en una ruta suele ser prepending deliberado, una señal de ingeniería de tráfico, no un bucle; y la ruta más corta no siempre es la que toma el tráfico real, porque el enrutamiento sigue la política comercial, no la geografía.
Calibra el instrumento antes de fiarte de él. Los colectores ven las vistas de las redes que hacen peering con ellos — una muestra grande y bien situada, pero no cada router del planeta. Un prefijo puede ser invisible para los colectores y aun así alcanzable dentro de un proveedor que no hace peering con RIS, y visible para los colectores mientras un tránsito concreto lo filtra más adelante. El resultado de un looking glass es evidencia sobre la tabla global vista desde puntos de observación serios. No es una fotografía de cada decisión de reenvío que se está tomando sobre tu prefijo ahora mismo.
RPKI en términos sencillos
RPKI es el intento de internet de hacer de «puedo anunciar esto» una afirmación comprobable en lugar de un grito. El titular de un prefijo publica un ROA — una autorización de origen de ruta, un objeto firmado que declara que un ASN nombrado puede originar ese prefijo, hasta una longitud máxima declarada. Validadores como Routinator — el que está detrás de la comprobación de este sitio — obtienen los ROA de los anclajes de confianza de los cinco registros regionales (APNIC, ARIN, LACNIC, RIPE NCC y AFRINIC) y contrastan cada anuncio con ellos. Una declaración firmada cubre tu anuncio o no lo cubre; ese es todo el mecanismo.
Cada anuncio cae en uno de tres estados. Válido: un ROA cubre este prefijo, este ASN de origen y esta longitud. Inválido: un ROA cubre el prefijo pero el anuncio incumple sus términos — y la distinción dentro de inválido importa: invalid_asn significa que la red equivocada lo está originando, mientras que invalid_length significa que la red correcta anuncia un prefijo más específico de lo que el ROA permite. Desconocido (a menudo llamado not-found): ningún ROA cubre el prefijo en absoluto, así que no hay nada contra lo que comprobar.
Ahora, la honestidad. Inválido es evidencia, no prueba de un secuestro. Los ROA se emiten mal, quedan obsoletos tras una transferencia de prefijo, o se escriben con una longitud máxima que el equipo de operaciones olvida después al desagregar — el caso del ASN equivocado merece una llamada rápida, pero revisa tu propio papeleo antes de acusar a nadie. Y desconocido normalmente solo significa que nadie publicó un ROA; una gran parte de los prefijos del mundo sigue sin tener ninguno, así que desconocido es un hueco del sistema, no una marca contra el prefijo. Aun así, inválido tiene dientes reales: muchas redes grandes ahora descartan los anuncios inválidos directamente, de modo que un estado inválido puede ser la causa directa del agujero de alcanzabilidad con el que empezaste.
Una rutina de comprobación en cinco pasos
Descarta primero las capas más simples — un registro DNS nuevo aún propagándose (compruébalo con el comprobador de propagación DNS) o un puerto de servicio cerrado al exterior (compruébalo con el escáner de puertos) imitan a la perfección los fallos de enrutamiento. Después abre la consulta BGP y trabaja en orden. Paso uno, el prefijo: introduce la IP o el prefijo y confirma el anuncio que lo cubre y que de verdad transporta tu tráfico. Paso dos, el origen: lee el ASN de origen y su titular — el tuyo, el de tu proveedor, o el de un extraño. Paso tres, la visibilidad: cuántos pares de colectores lo ven, y ¿parece ese recuento el normal para este prefijo?
Paso cuatro, RPKI: válido, inválido (¿de qué tipo?) o desconocido — y si invalid_asn nombra a un extraño, escala antes de terminar la lista. Paso cinco, las rutas AS: qué upstreams transportan el anuncio, y ¿hay alguna red sentada en una ruta donde no pertenece? Después escríbelo mientras lo tienes delante: el prefijo, el ASN de origen y su titular, el recuento de visibilidad, el estado RPKI, las rutas que viste — y la hora, en UTC. Los datos de la herramienta vienen de RIPEstat y RIPE RIS y se cachean durante una hora aproximadamente, así que una captura sin marca de tiempo es una anécdota; una nota con ella es evidencia que puedes comparar con la siguiente comprobación.
Límites que conviene declarar
Tres límites pertenecen a cualquier informe que se alimente de estos datos. La cobertura de los colectores tiene sesgo: los pares de RIS son numerosos pero no están repartidos uniformemente — algunas regiones y algunos tipos de red están mucho mejor representados que otros, así que un recuento de visibilidad es una muestra, no un censo. La propagación tarda minutos, no segundos: un cambio legítimo que acabas de hacer puede legítimamente no ser visible aún, y una ruta retirada puede permanecer en los colectores después de que el tráfico real haya pasado a otra cosa; espera y vuelve a comprobar antes de declarar una solución o un desastre. La cobertura RPKI es parcial: con muchos prefijos aún sin ROA, la capa de validación solo puede juzgar la parte de la tabla que participa en ella.
Y el límite que más importa en una discusión: un resultado limpio aquí no prueba lo que contiene la tabla de tu propio router. Tus sesiones, tus filtros, tu preferencia local pueden hacer que tu rincón de internet difiera legítimamente de lo que ven los colectores. Usa la consulta BGP para establecer qué anuncia y ve el mundo; usa la tabla BGP de tu propio router para establecer qué estás haciendo tú al respecto. Un informe de incidente que mantiene esas dos afirmaciones separadas es uno que nadie tiene que retirar.
Preguntas frecuentes
¿Qué significa realmente RPKI inválido?
Que un ROA cubre el prefijo, pero este anuncio incumple sus términos: o el ASN de origen no es el que el ROA autoriza (invalid_asn) o el prefijo anunciado es más específico de lo que la longitud máxima del ROA permite (invalid_length). Es evidencia, no prueba de un secuestro — los ROA mal emitidos y obsoletos, y los prefijos a mitad de transferencia, también producen anuncios inválidos. Trátalo como urgente de todos modos: muchas redes grandes descartan las rutas inválidas, así que un estado inválido puede ser en sí mismo la razón por la que parte de internet no alcanza el prefijo.
¿Puede un looking glass ver la tabla de rutas de mi propio router?
No. Un looking glass muestra lo que colectores de rutas como RIPE RIS han recibido de las redes que hacen peering con ellos — una muestra grande y útil de la tabla global, pero no la vista de tu propio router. Tu router aplica tus sesiones, filtros y preferencia local, así que su tabla puede diferir legítimamente. Para tu propia vista no hay sustituto de preguntarle al propio router (su resumen BGP y sus consultas de rutas); usa el looking glass para lo que ve el mundo, y tu router para lo que estás haciendo tú.
¿Por qué dos looking glasses no están de acuerdo sobre el mismo prefijo?
Porque miran desde sillas distintas. Cada colector hace peering con un conjunto distinto de redes, así que uno puede recibir un anuncio que otro nunca escucha; también pueden consultar con minutos de diferencia mientras un cambio aún se propaga, y las redes del camino aplican su propio filtrado — incluido descartar rutas RPKI inválidas — de modo que puntos de observación distintos sostienen honestamente tablas distintas. El desacuerdo es información: si los colectores de una región ven el prefijo y los de otra no, la forma del desacuerdo es a menudo la forma del problema.