WireGuard aniñado: o salto intermedio non pode responder ao seu propio porto
Cando o salto intermedio envía todo por un só túnel, as respostas ao seu servizo de entrada saen polo camiño incorrecto. Unha regra de porto de orixe na interface arranxa iso.
Tres saltos de WireGuard chegan a unha rede sen enderezo público, e entón a máquina intermedia deixa de responder no porto no que debía escoitar. O túnel cara adiante segue funcionando, o host remoto segue respondendo, e só o servidor intermedio quedou calado desde fóra. Esa combinación desconcerta precisamente porque é autoinxerida: o salto intermedio obedece a súa propia táboa de enrutamento, e a táboa envía as súas respostas polo camiño incorrecto.
Unha cadea que funciona ata que falas coa caixa intermedia
Collamos unha cadea ilustrativa: o cliente A chega ao servidor B por UDP 500, e B chega máis alá ao servidor C por UDP 500. C só acepta tráfico do enderezo do seu único par, o que o converte nunha folla e mantén simple o seu comportamento. B non é unha folla, e todo o interesante deste fallo ocorre alí.
A distinción importa porque os papeis de folla e intermedio tiran en direccións opostas. Unha folla pode envialo todo por un só túnel sen consecuencias, xa que nada máis depende dela. Un salto intermedio é á vez un punto final para os clientes e un cliente cara ao lado remoto, e eses dous traballos queren un enrutamento distinto.
Por que a resposta sae polo túnel
En B, a interface que mira cara a C leva AllowedIPs = 0.0.0.0/0 xunto coa ruta predeterminada correspondente. Por tanto, cada paquete que B orixina entra nese túnel, salvo que algo máis específico teña prioridade.
Un paquete de A dirixido a B chega e acéptase, porque B é o destino e a entrega local ocorre primeiro. A resposta é un paquete completamente novo xerado localmente e dirixido ao enderezo público de A, e ese destino coincide coa ruta predeterminada cara ao túnel. C recíbeo, non posúe ese enderezo e descártao.
O síntoma lese como un problema de devasa ou un desaxuste de chaves, e aquí ningunha das dúas cousas é certa. Unha captura no túnel cara a C mostra que as respostas van na dirección incorrecta. Esa única observación aforra máis tempo que calquera cantidade de lectura de configuración, así que anótea antes de comezar a cambiar chaves. Quen non vise a captura asumirá que o túnel mesmo está roto.
A reparación estreita: regras de política que coinciden cun porto de orixe
As respostas do socket de escoita de B saen co porto de orixe 500. Unha regra de política pode coincidir con iso e devolver eses paquetes á táboa ordinaria:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101As regras de política consúltanse por orde de prioridade, e a táboa principal está en 32766, así que unha regra en 100 pregúntase antes de que a ruta predeterminada do túnel teña algo que dicir. Engade unha entrada por cada porto que deba seguir sendo accesible desde fóra e nada máis, para que o tráfico reenviado siga usando o túnel para o que se construíu.
Coñece o límite deste truco. O selector sport coincide con paquetes xerados localmente, o que cobre exactamente o caso da resposta e deliberadamente non cobre o tráfico que B só reenvía para outro. Un servizo aloxado detrás de B aínda necesita a súa propia resposta, e finxir o contrario produce unha solución que funciona para o primeiro servizo e falla para o segundo.
Dálle un dono á regra
Unha regra escrita nun indicador desaparece a próxima vez que se reconstrua a interface. Nunha instalación de WireGuard, pona onde se crea e se elimina a interface:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100Se NetworkManager, un gancho da distribución ou un punto de entrada de contedor é o dono da interface, o par pertence a ese dono e non a un ficheiro editado á man. Comproba as regras efectivas tras unha reconexión, non só tras o primeiro arranque, porque o primeiro arranque é o caso que sempre funciona.
Compara as alternativas con honestidade
A regra de porto de orixe é unha de catro saídas, e é a máis estreita de todas. Ten a vantaxe de non tocar en absoluto a política do túnel, e por iso adoita sobrevivir aos cambios posteriores. As reparacións estreitas tamén fallan ruidosamente cando deixan de aplicarse, mentres que unha excepción ampla segue funcionando en silencio moito despois de que a razón desaparecese. Esa diferenza importa máis que a elegancia cando outra persoa é dona da caixa dentro de dous anos.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
Verifica desde ambos os extremos unha vez que escollas. Desde A, inicia unha conexión ao porto de B e mantena ocupada un intre. En B, fai que o núcleo xustifique a ruta de resposta con algo como ip route get <address-of-A> sport 500, e confirma que nomea a interface WAN en lugar do túnel. Despois, comproba que algo detrás de C segue respondendo a través da cadea, o que demostra que a excepción seguiu sendo estreita en vez de converterse nun desvío. Por último, anota os portos nas notas de deseño, ou o seguinte operador redescubrirá isto noutro servizo.