A resposta sae pola LAN, non polo túnel: por que e como

Un servizo publicado a través dunha pasarela funciona desde a maior parte de internet e falla desde unha oficina. Alguén revisa o túnel, ve chegar a solicitude e conclúe que a resposta debe seguir o mesmo camiño de volta. Linux non funciona así, e ningunha inspección do túnel cambiará a resposta. A resposta encamiñase por destino, e ese único solicitante que falla está nunha subrede á que o equipo xa chega directamente.

Que decide realmente un paquete de saída

O núcleo busca unha ruta para o destino do paquete, consultando as regras de política por orde de prioridade e despois a táboa que selecciona unha regra coincidente. A interface pola que chegou un paquete non inflúe, salvo que se escribise unha regra ou unha marca para que importe. É un feito de encamiñamento deste equipo, non un fallo do túnel.

Por tanto, unha solicitude recibida polo túnel pode producir unha resposta que sae pola interface física, e o fluxo vólvese unidireccional sen que ningún dispositivo informe dun erro. Comproba ambas as direccións antes de sacar unha conclusión sobre o túnel. Unha resposta que sae polo lado equivocado desaparece dos contadores do túnel, e por iso os dous extremos non coinciden sobre se se enviou algo. Fíxate en que contador se moveu antes de tocar unha regra.

Por que gaña a subrede local

Un equipo cun enderezo nunha rede local ten unha ruta conectada para ese prefixo na táboa principal, e unha ruta conectada é unha coincidencia directa. Cando o solicitante vén desa mesma subrede, a busca atopa a ligazón local antes de que o túnel se considere sequera.

A asimetría é o que fai que o diagnóstico sexa confuso. Os solicitantes do resto de internet funcionan porque non coinciden con ningunha ruta local, mentres que o único solicitante que comparte o prefixo da oficina falla, que é xusto o solicitante co que alguén proba.

A cobertura de pares non é o mesmo que as rutas instaladas

No lado do túnel, os rangos permitidos dun par describen que se pode enviar ao túnel e que fontes se aceptan del. Non din nada sobre onde enviará un paquete a táboa de encamiñamento local.

Se a ferramenta do túnel instala unha ruta predeterminada no equipo, pode arrastrar tráfico non relacionado ao túnel como dano colateral. Onde unha regra de política debería ser a dona da decisión, a opción de instalación de rutas da ferramenta existe precisamente para impedilo, e os enderezos, as claves e a configuración do extremo quedan exactamente como estaban. Unha ruta predeterminada engadida por comodidade é unha forma habitual de que un equipo perda a súa propia rede local.

Escolle a táboa pola dirección de orixe

Unha regra baseada na orixe envía as respostas desde o enderezo do servizo a unha táboa privada cuxo valor predeterminado é o túnel, mentres que todo o demais segue usando a táboa principal. Escolle números de táboa e de prioridade que non se usen localmente, e le as regras existentes antes de inserir nada. Le as regras activas en lugar dun ficheiro gardado, porque ambos poden diferir tras un reinicio.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

A última liña fai que unha ruta ausente falle de forma visible en lugar de recaer na ligazón local. A orixe debe estar realmente asignada ao equipo, e as buscas locais e principais ordinarias deben permanecer nas súas posicións anteriores. A regra escolle unha táboa por orixe; non compara lonxitudes de prefixo entre táboas.

Confirma o camiño e despois o servizo

Pregunta ao núcleo que faría en lugar de inferilo dunha captura, usando o enderezo do servizo como selector de orixe. Unha resposta equivocada aquí aforra todo un rastrexo de paquetes.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

A saída debería nomear o túnel. Despois proba unha orixe que non tocases e confirma que segue tomando a ligazón local, de xeito que o cambio quedou limitado a un enderezo. Un selector máis amplo non demostraría nada sobre a queixa orixinal.

Que non arranxa isto

Deixa o reenvío, as regras da devasa e o comportamento de ICMPv6 na pasarela como estaban, porque unha ruta de orixe non substitúe ningunha delas. Unha mensaxe Packet Too Big ausente segue rompendo as respostas grandes, gañe a busca a táboa que gañe. Corrixe iso antes de engadir regras de encamiñamento, ou o síntoma sobrevivirá ao cambio.

Confirma o modelo de publicación antes de aplicar nada disto. Un proxy inverso que abre a súa propia conexión de backend presenta a súa propia orixe e non conserva o solicitante, así que este fallo non pode ocorrer nese deseño. Aplicar a regra alí engadiría unha excepción de encamiñamento que non resolve nada e oculta a causa real.

Por último, escribe os números de regra e a táboa na xestión de configuración do equipo. Unha regra de política engadida a man desaparece na seguinte reconstrución, e o solicitante da oficina volve coa mesma queixa.