Como distinguir un bucle de enrutamento dunha ruta que fluctúa en sitios VPN
Un bucle de enrutamento e unha ruta inestable causan a mesma perda intermitente. Tres comprobacións nas pasarelas distínguenos antes de que cambie nada.
Dous sitios, un túnel e un prefixo remoto que responde un tempo e despois cala. O reflexo é chamalo bucle de enrutamento, e ás veces é exactamente iso. Pero un bucle e unha ruta inestable producen a mesma queixa e necesitan reparacións opostas: un é unha decisión de reenvío que nunca remata, a outra é un prefixo que non deixa de saír da táboa. Tres observacións sepáranos, e pode reunir as tres desde a liña de ordes da pasarela antes de tocar un filtro ou reiniciar un túnel.
Un bucle decídese salto a salto. O sitio A elixe B como seguinte salto para o destino, B elixe A para o mesmo destino, e o paquete caduca no TTL tras dúas viaxes de ida e volta. Unha fluctuación decídea en cambio o protocolo de enrutamento: o prefixo retírase, reinstálase ou substitúese por un seguinte salto alternativo, así que algúns paquetes non teñen ruta ningunha mentres outros seguen unha perfectamente boa.
As tres comprobacións que resolven a cuestión
Non precisa unha captura de paquetes para tomar a primeira decisión. Precisa o estado do prefixo nos dous extremos, o seguinte salto que elixe cada lado e un número de saltos que se repite ou non. Se o prefixo segue instalado co mesmo seguinte salto mentres falla o tráfico, o bucle vive na ruta de reenvío. Se o prefixo desaparece e volve, o fallo está por riba do reenvío e a reparación corresponde ao protocolo de enrutamento, non a unha ruta estática.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
Unha advertencia antes de comezar. Se le isto a través do túnel que está en bucle, a súa sesión morre no momento en que cambie a ruta. Abra unha consola ou unha vía de xestión que non dependa do prefixo que está a piques de reparar.
Comprobación un: o prefixo é estable ou axítase
Pregunte ao núcleo que instalou, non que promete o ficheiro de configuración. Nunha pasarela Linux, ip route get 10.20.30.40 executa a mesma consulta que executa a ruta de reenvío, incluídas as táboas de políticas, mentres que ip route show 10.20.30.0/24 mostra a entrada mesma. ip monitor route transmite cada cambio no momento en que ocorre, que é a forma máis rápida de ver un prefixo chegar e marchar.
Nun encamiñador con FRR ou BIRD, a táboa de reenvío non é a interesante. show ip bgp 10.20.30.0/24 devolve a ruta seleccionada e o seu tempo de actividade; un tempo de actividade que se reinicia cada poucos minutos é unha fluctuación que pode nomear, non un bucle. show ip bgp summary mostra o estado dos veciños e as contas de prefixos, así que un par que cae sen parar quita a culpa á ruta de reenvío.
Anote a resposta antes de cambiar nada. Estable durante dez minutos mentres fallaban os pings, e desaparecido catro veces en dez minutos, levan a pasos seguintes distintos. O segundo caso fai irrelevante calquera teoría de ruta estática.
Comprobación dous: o seguinte salto apunta de volta ao túnel de chegada
Un bucle necesita que dúas pasarelas se poñan de acordo. No sitio que recibe o paquete, mire a ruta que usará o paquete para saír: ip route get 10.20.30.40 from 10.10.5.20 co enderezo de orixe real, porque unha regra de política pode responder distinto da táboa principal. Logo repita a consulta no sitio que o enviou. Se cada lado elixe o outro como seguinte salto para o mesmo prefixo, o bucle queda probado e ningunha captura engadirá nada.
A causa é case sempre un anuncio que non debería ter cruzado o túnel. Unha ruta por defecto redistribuída dentro do túnel, un agregado que cobre a propia subrede do sitio remoto ou unha ruta estática cara ao par por se acaso crean todos o mesmo seguinte salto mutuo. O túnel pode estar plenamente establecido e aínda así levar tráfico en círculo; as notas de reenvío de strongSwan describen o lado de enrutamento dese requisito.
WireGuard merece a súa propia nota, porque non hai anuncio a quen culpar. wg show lista as AllowedIPs de cada par, e o núcleo acepta un destino para un par só se cae dentro dese rango. Un bucle aí é un rango de AllowedIPs superposto ou unha ruta estática que apunta cara atrás a través da interface, así que a reparación vive neses dous lugares e en ningún outro.
Comprobación tres: lea o número de saltos, non as estrelas
traceroute -n -I 10.20.30.40 e mtr -n -r -c 20 10.20.30.40 mostran ambos a ruta, e o modo ICMP adoita sobrevivir a un filtrado que come as sondas UDP. Un bucle parece unha secuencia curta e repetida dos mesmos dous enderezos de pasarela co TTL subindo cada vez. Unha caída parece estrelas tras a última pasarela que respondeu, e un só salto silencioso non é proba de nada.
Cando a ruta é ambigua, lea o TTL no cable. tcpdump -ni any -vv icmp en ambas as pasarelas mostra o TTL de cada paquete e o enderezo de orixe de cada resposta de tempo excedido. Se un paquete chega ao sitio remoto cun TTL inferior ao número de saltos que a ruta pode conter, algo engade saltos que traceroute non lle mostra, o que ocorre cando o cortafuegos dun sitio responde ás sondas no nome doutro.
Repare o propietario do prefixo e logo verifique ambas as direccións
Decida que sitio orixina o destino e que rutas de tránsito están permitidas, e logo cambie o anuncio ou a ruta estática nese propietario. Corrixir o sitio receptor é tentador e adoita ser erróneo: agocha o bucle para un prefixo e deixa o anuncio malo no seu sitio para o seguinte. As etiquetas de ruta, as listas de distribución e as regras de horizonte dividido existen para deter isto na orixe, e son máis baratas que un filtro que coincide cun só prefixo.
Despois do cambio, verifique a ida e a volta por separado, porque un bucle pode ser substituído por un burato negro sen ningunha mellora visible do síntoma. Execute ip route get desde ambos os extremos, envíe tráfico desde un equipo que non sexa a pasarela e deixe ip monitor route en marcha polo menos un temporizador de retención para que unha fluctuación non se confunda cunha reparación.
Antes de cambiar nada, confirme estes cinco puntos: o prefixo é estable ou axítase, o seguinte salto en ambos os extremos apunta a un túnel, o número de saltos repítese ou non, un só sitio posúe o prefixo e vostede ten unha vía de xestión que sobrevive ao cambio. Se un dos cinco é descoñecido, os outros catro son conxecturas.