Cando as rutas do túnel dividido se superpoñen: que prefixo gaña

Dous perfís de túnel dividido, dous prefixos privados e un servidor que ambos reclaman. O síntoma raramente é un fallo limpo: un servizo funciona o luns, deixa de responder tras reconectarse o segundo cliente e volve funcionar despois de reiniciar. A orde na que conectou os clientes non decide o resultado, nin tampouco a orde das filas na interface do cliente. Execute estas comprobacións en orde e detéñase na primeira que non se cumpra, porque as posteriores só teñen sentido cando as anteriores son certas.

1. Anote o destino e a orixe

Comece polo enderezo exacto ao que vai a petición que falla, non polo nome do servidor nin polo nome da aplicación. Resolva o nome unha vez, anote cada resposta e escolla a que o fluxo que falla usa realmente. Despois anote o enderezo local do mesmo fluxo, porque o enderezo de orixe pode cambiar que regra de política coincide e, por tanto, que táboa se consulta.

Unha petición a un de varios rexistros A pode fallar mentres un enderezo irmán ten éxito, o que parece un túnel inestable e en realidade son dous camiños distintos. Se o destino é un nome con varias respostas, probe cada resposta por separado antes de cambiar algo.

2. Pregunte ao núcleo que ruta escolleu

Non lea a táboa de rutas e deduza a resposta. Faga a mesma pregunta que fai a pila, co mesmo enderezo de orixe: ip route get 10.20.4.10 from 10.8.0.2 en Linux, ou Find-NetRoute -RemoteIPAddress 10.20.4.10 en PowerShell. A saída nomea a ruta que se usaría realmente, que a miúdo non é a que esperaba ao ler a táboa.

Entre as rutas que coinciden, normalmente gaña o prefixo máis específico: un /24 vence un /16 para un enderezo dentro de ambos. Entre coincidencias da mesma lonxitude gaña a métrica máis baixa, e unha ruta instalada nunha ligazón caída omítese. Dous túneles que anuncian o mesmo /24 coa mesma métrica son un caso distinto: o núcleo conserva ambas as rutas e escolle entre elas, así que o resultado pode alternar en lugar de seguir a orde na que se conectaron os clientes. Esa é exactamente a situación que produce o patrón de luns funciona e martes falla, e reconectar noutra orde non o cambia.

3. Comprobe se unha regra de política redirixiu a consulta

Antes de consultar a táboa de rutas, o núcleo percorre as súas regras de política. Unha regra pode enviar o tráfico dunha orixe, usuario ou marca de devasado determinados a unha táboa completamente distinta, así que o prefixo gañador da táboa principal pode non consultarse nunca para ese fluxo. ip rule show enuméraas en orde de avaliación, e ip route show table 100 mostra que contén realmente a táboa seleccionada.

Aquí axexan dúas trampas. Unha regra que apunta a unha táboa baleira produce unha consulta que cae á regra seguinte, así que a regra parece non facer nada. A outra é o propio número de prioridade: as regras len en orde ascendente, e os valores integrados son 0 local, 32766 main e 32767 default. Unha regra cun número inferior a 32767 consúltase antes da regra predeterminada que o captura todo. Unha regra cun número superior a 32767 queda detrás dela e só se alcanza cando ningunha táboa anterior responde, algo que unha ruta predeterminada normal en main impide, así que na práctica nunca se alcanza e non fai nada en silencio mentres parece instalada. Se o cliente escribiu unha regra e unha ruta, comprobe ambas e vólvaas comprobar tras unha reconexión, porque un perfil reescrito pode engadir unha segunda regra con outra prioridade.

4. Separe un empate de encamiñamento dun plan de enderezos duplicado

Ás veces o prefixo non é o problema en absoluto. Dous sitios que usan ambos 192.168.1.0/24 significan que o mesmo enderezo identifica dous servidores distintos e ningunha ruta pode distinguilos. Unha ruta de servidor cara a unha das dúas respostas só funciona ata que o outro sitio responda polo mesmo nome, e entón a excepción convértese en silencio no fallo.

A pista é que o enderezo de destino é idéntico nos dous camiños e só difire o propietario previsto. Iso é unha decisión de plan de enderezos, non un axuste de encamiñamento: renumere un lado, coloque un lado detrás dunha pasarela que traduza, ou chegue ao segundo sitio mediante un proxy que resolva os seus propios nomes. Baixar unha ruta predeterminada ou acumular excepcións de servidor só traslada a colisión a outro sitio.

5. Confirme que o resolutor coincide coa ruta

Un nome que se resolve ao enderezo privado incorrecto produce todos os síntomas dun conflito de encamiñamento e ningunha das súas causas. Compare a resposta que recibe o servidor co enderezo que o destino usa realmente, e comprobe que resolutor respondeu. Se o túnel empuxa un resolutor, o cliente debería instalalo para os fluxos que usan o túnel; se non o fai, o servidor segue preguntando ao resolutor local, que pode responder desde un dominio de busca ou desde un rexistro na caché.

Consulte o resolutor directamente e anote o servidor que respondeu. Unha resposta na caché cun TTL curto tamén pode explicar por que a primeira petición tras unha reconexión se comporta de forma distinta á quinta.

6. Reconecte, inspeccione o estado aplicado e despois probe ambos os fluxos

Tras unha corrección, reconecte e inspeccione que instalou realmente o cliente en lugar de confiar no editor de perfís. Volva ler as regras, as táboas e a resposta de ip route get resultante. Un segundo cliente pode reinstalar a súa propia ruta ao conectarse e recrear o conflito, polo que a comprobación de estado debe ocorrer despois de que se conecte o último cliente, non antes.

Probe dous fluxos, non un: a petición que antes fallaba e un recurso que debe usar o outro túnel. Mover todo o tráfico privado a unha soa conexión fará que a primeira proba pase mentres rompe a segunda, e só unha proba emparellada o detecta. Anote cada excepción que conserve, co destino e o motivo, para que a seguinte persoa poida distinguir unha ruta de servidor deliberada dunha sobrante.