Como verificar rotas BGP e a validade RPKI

Quando as rotas correm mal

O cenário é familiar a quem já operou um serviço público: o site carrega para si, o servidor está saudável, o certificado é válido — e os clientes de outro país não obtêm nada. A monitorização a partir do seu próprio escritório diz que está tudo bem. O tráfego deles nunca chega, porque a alcançabilidade não é uma propriedade do seu servidor. É uma propriedade dos anúncios que transportam o seu prefixo através das redes dos outros, e esses anúncios podem mudar, ser filtrados ou ser contraditos sem que nada na sua máquina mude. “O site está em baixo” é por vezes um facto de encaminhamento com fato de servidor.

As falhas de rota têm três formas que vale a pena distinguir. Um sequestro: outro sistema autónomo anuncia o seu prefixo — ou uma fatia mais específica dele — e atrai tráfego que nunca foi seu. Uma fuga de rotas: uma rede propaga rotas que recebeu para pares ou fornecedores a quem não as devia ter enviado, de modo que o tráfego faz desvios absurdos ou cai numa rede que não o consegue entregar. E a silenciosa: um anúncio retirado ou filtrado por uma mudança de configuração, uma disputa de peering ou um descarte RPKI, de modo que parte da internet simplesmente fica sem caminho. As correções para as três são inteiramente diferentes, e por isso o primeiro trabalho é distingui-las — e isso começa por olhar para o que é realmente anunciado.

Comece pelo anúncio

A primeira pergunta é a mais simples: este prefixo é anunciado para a tabela global de todo e, se sim, por quem? O último AS do anúncio — o ASN de origem — nomeia a rede que afirma deter o prefixo, e os dados de registo por trás dele nomeiam a organização a que esse ASN pertence. Se a origem for o seu próprio ASN, ou o do seu fornecedor, o anúncio pelo menos reclama a casa certa. Se for um nome que nunca viu, aprendeu algo importante nos primeiros dez segundos.

Os casos limite carregam a informação. Um prefixo sem qualquer origem não está a ser anunciado em nenhum lugar que os coletores consigam ver — um erro de digitação no prefixo, um anúncio nunca feito, ou um retirado em todo o lado; verifique se existe um prefixo menos específico que o cubra antes de concluir o que quer que seja, porque o tráfego pode continuar a fluir sob o agregado. Várias origens para um prefixo não são automaticamente suspeitas: os serviços anycast e os grandes CDN originam o mesmo prefixo a partir de muitas redes por desenho, e um prefixo a meio de uma transferência entre fornecedores pode mostrar duas origens legitimamente durante algum tempo. Várias origens mais um titular que não reconhece, a começar num momento em que não mudou nada: é essa a combinação que merece alarme.

Visibilidade e caminhos AS

Um looking glass não pergunta ao seu router; pergunta aos coletores de rotas — os coletores RIPE RIS por trás dos dados deste site fazem peering com redes de todo o mundo e registam o que esses pares lhes anunciam. A visibilidade é a contagem de pares de coletores que veem o seu prefixo de todo. Um prefixo saudável e antigo é tipicamente visto por quase todos. Uma contagem em queda livre — ou uma que ontem estava cheia e hoje é um punhado — sugere um anúncio a ser retirado, filtrado, ou visto apenas através de um conjunto de caminhos que se estreita.

O caminho AS é a cadeia de redes que um anúncio percorreu: leia-o da direita para a esquerda, da origem para fora através dos fornecedores de trânsito até ao par do coletor. Diz-lhe que upstreams transportam a rota e onde o seu próprio fornecedor se senta na cadeia — e quando acontece uma fuga, o caminho mostra a rede que não devia lá estar, no meio, a reencaminhar o tráfego de lado. Um hábito de leitura a construir: um ASN repetido num caminho é normalmente prepending deliberado, um sinal de engenharia de tráfego, não um ciclo; e o caminho mais curto nem sempre é o que o tráfego real toma, porque o encaminhamento segue a política comercial, não a geografia.

Calibre o instrumento antes de confiar nele. Os coletores veem as vistas das redes que fazem peering com eles — uma amostra grande e bem colocada, mas não cada router do planeta. Um prefixo pode ser invisível para os coletores e ainda assim alcançável dentro de um fornecedor que não faz peering com o RIS, e visível para os coletores enquanto um trânsito específico o filtra mais adiante. O resultado de um looking glass é evidência sobre a tabela global vista de pontos de observação sérios. Não é uma fotografia de cada decisão de reencaminhamento a ser tomada sobre o seu prefixo neste momento.

RPKI em linguagem simples

O RPKI é a tentativa da internet de tornar “tenho permissão para anunciar isto” uma afirmação verificável em vez de um grito. O titular de um prefixo publica um ROA — uma Autorização de Origem de Rota, um objeto assinado que declara que um ASN nomeado pode originar esse prefixo, até um comprimento máximo declarado. Validadores como o Routinator — o que está por trás da verificação deste site — vão buscar os ROA às âncoras de confiança dos cinco registos regionais (APNIC, ARIN, LACNIC, RIPE NCC e AFRINIC) e testam cada anúncio contra eles. Uma declaração assinada cobre o seu anúncio ou não cobre; é todo o mecanismo.

Cada anúncio cai num de três estados. Válido: um ROA cobre este prefixo, este ASN de origem e este comprimento. Inválido: um ROA cobre o prefixo, mas o anúncio quebra os seus termos — e a distinção dentro de inválido importa: invalid_asn significa que a rede errada o está a originar, enquanto invalid_length significa que a rede certa anuncia um prefixo mais específico do que o ROA permite. Desconhecido (muitas vezes chamado not-found): nenhum ROA cobre o prefixo de todo, logo não há nada contra o que verificar.

Agora a honestidade. Inválido é evidência, não prova de um sequestro. Os ROA são mal emitidos, ficam obsoletos depois de uma transferência de prefixo, ou são escritos com um comprimento máximo que a equipa de operações depois esquece ao desagregar — o caso do ASN errado merece um telefonema rápido, mas verifique a sua própria papelada antes de acusar quem quer que seja. E desconhecido normalmente significa apenas que ninguém publicou um ROA; uma grande parte dos prefixos do mundo ainda não tem nenhum, logo desconhecido é uma lacuna do sistema, não uma marca contra o prefixo. Ainda assim, inválido tem dentes reais: muitas redes grandes agora descartam anúncios inválidos de imediato, de modo que um estado inválido pode ser a causa direta do buraco de alcançabilidade com que começou.

Uma rotina de verificação em cinco passos

Exclua primeiro as camadas mais simples — um registo DNS novo ainda a propagar-se (verifique-o com o verificador de propagação DNS) ou uma porta de serviço fechada ao exterior (verifique-a com o scanner de portas) imitam na perfeição as falhas de encaminhamento. Depois abra a consulta BGP e trabalhe por ordem. Passo um, o prefixo: introduza o IP ou o prefixo e confirme o anúncio que o cobre e que transporta mesmo o seu tráfego. Passo dois, a origem: leia o ASN de origem e o titular — o seu, o do seu fornecedor, ou o de um estranho. Passo três, a visibilidade: quantos pares de coletores o veem, e essa contagem parece a normal deste prefixo?

Passo quatro, RPKI: válido, inválido (de que tipo?) ou desconhecido — e se invalid_asn nomear um estranho, escale antes de terminar a lista. Passo cinco, os caminhos AS: que upstreams transportam o anúncio, e há alguma rede sentada num caminho onde não pertence? Depois escreva-o enquanto o tem diante de si: o prefixo, o ASN de origem e o titular, a contagem de visibilidade, o estado RPKI, os caminhos que viu — e a hora, em UTC. Os dados da ferramenta vêm do RIPEstat e do RIPE RIS e ficam em cache durante cerca de uma hora, logo uma captura de ecrã sem marca temporal é uma anedota; uma nota com ela é evidência que pode comparar com a verificação seguinte.

Limites que vale a pena declarar

Três limites pertencem a qualquer relatório que estes dados alimentem. A cobertura dos coletores é enviesada: os pares do RIS são numerosos, mas não estão distribuídos uniformemente — algumas regiões e alguns tipos de rede estão muito melhor representados do que outros, logo uma contagem de visibilidade é uma amostra, não um censo. A propagação demora minutos, não segundos: uma mudança legítima que acabou de fazer pode legitimamente ainda não ser visível, e uma rota retirada pode permanecer nos coletores depois de o tráfego real ter mudado; espere e volte a verificar antes de declarar uma correção ou um desastre. A cobertura RPKI é parcial: com muitos prefixos ainda sem ROA, a camada de validação só pode julgar a parte da tabela que nela participa.

E o limite que mais importa numa discussão: um resultado limpo aqui não prova o que a tabela do seu próprio router contém. As suas sessões, os seus filtros, a sua preferência local podem todos fazer o seu canto da internet divergir legitimamente do que os coletores veem. Use a consulta BGP para estabelecer o que o mundo anuncia e vê; use a tabela BGP do seu próprio router para estabelecer o que está a fazer quanto a isso. Um relatório de incidente que mantém essas duas afirmações separadas é um que ninguém tem de retirar.

Perguntas frequentes