WireGuard envía datos pero non recibe nada de volta: que lado?
Un contador de transmisión que sobe é unha dirección, non un diagnóstico. Decida se a petición nunca saíu do túnel ou se a resposta nunca volveu antes de tocar nada.
Os contadores de transmisión que soben mentres o contador de recepción queda en cero describen unha dirección, non un diagnóstico. A mesma lectura aparece cando o par nunca completou un handshake, cando o destino escolleu o par equivocado, cando o lado remoto non ten ruta de volta e cando un filtro descarta a resposta de camiño á casa. Cada un deses casos repárase nun lugar distinto.
A comparación que acurta o traballo está entre unha petición que nunca saíu do túnel e unha resposta que nunca volveu. Unha captura na interface correcta decide entre ambas.
Os contadores describen volume, non a dirección da avaría
Os contadores de WireGuard rexistran o que a interface entregou ao par e o que recibiu del. Non din que destino, que par ou que metade dun intercambio fallou. O tráfico de fondo fai que os totais sexan aínda menos informativos, xa que algúns bytes poden ser mensaxes de mantemento ou fluxos non relacionados. Léaos como un indicio de que a interface está activa e logo deixe de tratalos como proba.
O primeiro dato útil é se o handshake está vixente. Sen el non se cifrou nada para este par e o contador de recepción non ten motivo para moverse.
Selección do par ou camiño da resposta: dúas explicacións
A primeira explicación é que o paquete nunca chegou ao par previsto, porque a ruta apuntaba a outro sitio ou porque os prefixos permitidos do par non cubrían o destino. A segunda é que o paquete chegou e a resposta non puido volver, o que é un problema de encamiñamento no extremo remoto. A táboa sepáraos segundo o que observaría en cada punto.
| Observation | Points to |
|---|---|
| No handshake while transmit climbs | Peer selection or endpoint |
| Handshake current, request visible on the server | Reply path or far-side route |
| Request never visible on the server | Allowed prefixes or local route |
| Both packets visible, nothing reaches the client | Return filter or translation |
Lea a táboa desde arriba. Un handshake ausente envíao ás claves, aos extremos e ao camiño exterior, porque aínda non hai nada máis que examinar. Un handshake vixente coa petición visible no servidor traslada o problema á dirección de volta, onde decide a propia táboa de rutas do destino. Unha petición que nunca aparece no servidor é un problema de selección, e os prefixos permitidos nos dous pares son o primeiro que hai que comparar.
Dúas desas catro filas repáranse no cliente e dúas no servidor. Saber en que parella está é a maior parte do traballo.
Onde desaparecen as respostas
Unha resposta sae do destino, chega á interface de túnel do servidor e cífrase para o par cuxas direccións permitidas coinciden coa dirección interna do cliente. Se esa coincidencia falla, a resposta descártase en silencio, o que desde o lado do cliente parece exactamente unha avaría de rede. Se a resposta está cifrada e o propio filtro do cliente a rexeita, o síntoma volve ser idéntico. Ambos os casos necesitan a captura e non o contador.
A versión máis forte deste erro é un servidor que reenvía paquetes para o cliente pero non ten ruta de volta ao rango interno do cliente. Acepta a petición, envía a resposta cara á súa pasarela predeterminada e o túnel nunca a ve. Unha regra de tradución ampla engadida ao servidor oculta esa avaría en lugar de reparar a ruta.
Probe un só destino de extremo a extremo
Escolla un único destino dentro do rango do par e próbeo mentres o handshake sexa demostrablemente vixente. Os comandos seguintes len o estado do par, a ruta escollida e ambos os lados do intercambio. Execute a captura na interface que usan realmente os paquetes cifrados.
wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5Unha captura que mostra a petición na interface de túnel sen nada de volta é unha resposta do lado do servidor, e a táboa de rutas do destino é o seguinte lugar onde mirar. Se non aparece absolutamente nada, o paquete tomou outro camiño, así que a ruta local é a sospeitosa. Un intercambio visible en ambas as capturas sen progreso na aplicación traslada a pregunta ao tamaño do paquete ou a un filtro que as estatísticas da interface nunca mostran. Manteña un destino e un cliente na proba, porque unha segunda variable converte a evidencia outra vez nunha impresión.
Se os nomes fallan mentres unha dirección permitida funciona, a resposta está en DNS e non no túnel. Se só se atascan as transferencias grandes, examine o tamaño do paquete por separado.