A aperta de mans de WireGuard compleméntase, pero non volve ningunha resposta

As apertas de mans recentes son unha boa nova e unha afirmación moito máis modesta ca frase que un quere escribir. As parellas intercambiaron mensaxes de aperta de mans autenticadas. Un paquete de aplicación aínda ten que chegar ao seu destino interno e volver.

Ese oco entre un plano de control san e un plano de datos silencioso é todo o tema aquí. Dúas lecturas dos mesmos contadores dinlle de que lado está.

A aperta de mans demostra claves, non entrega

A aperta de mans de WireGuard é un acordo de claves con autenticación. Complétase en canto as parellas poden alcanzarse e teñen claves válidas. O encamiñamento, a política da devasa e o propio destino son preguntas que a aperta de mans nunca fai.

Así que un túnel pode estar perfectamente establecido mentres cada paquete dentro del se descarta. Un paquete interno mal encamiñado e unha resposta que toma outro camiño vense igual desde o cliente.

Un só enderezo interno é toda a proba

Escolla un destino e quédese con el. O enderezo de túnel da propia parella é o caso máis doado, e un equipo detrás da parella engade exactamente un salto. Alternar entre ambos sen anotar o cambio produce resultados que ninguén pode comparar.

Despois mire a ruta que escolle o cliente. Unha ruta local máis específica pode enviar o paquete a outro sitio antes de que se consulte WireGuard, o que ocorre sempre que a LAN da casa se solapa co rango remoto.

ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0

Un enderezo que se resolve na interface física xa respondeu á pregunta. O túnel non descarta nada. O paquete nunca entrou nel.

Os contadores son probas, non un veredicto

wg show informa dos bytes enviados e recibidos por parella, e os dous números móvense de forma independente. Tome unha lectura, faga unha petición permitida e logo tome outra lectura dentro do mesmo minuto.

wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer

Os envíos que soben coas recepcións planas son a sinatura dunha petición sen resposta. Non di se a petición se filtrou, se o destino estaba caído ou se a resposta saíu por outra ruta. Son tres investigacións que comparten un síntoma. Sepáreas antes de cambiar calquera configuración.

Un número fixo de bytes tampouco é un limiar de éxito. Os valores dos contadores seguen o tráfico, e tratar un só número como proba de saúde produce desatinos con moita seguridade.

A parella comproba ela mesma o paquete de volta

A parella remota acepta un paquete interno só cando a orixe cae dentro do seu allowedips. Unha ruta que exista no emisor non abonda. Unha entrada de orixe ausente no receptor descarta o tráfico de volta en silencio.

As devasas do equipo están detrás desa comprobación. Unha regra de reenvío que permite a interface do túnel pero non a subrede interna acepta a aperta de mans e rexeita o paquete. Desde o lado do cliente iso parece exactamente unha parella morta. Un equipo con dúas interfaces tamén pode responder desde a orixe equivocada, e entón a parella descarta a resposta que nunca esperou.

Manteña o experimento honesto

Probar un perfil de acceso remoto desde a mesma rede da casa á que debe chegar exercita un camiño distinto do previsto. Páse á rede externa e anote o seu prefixo local, para que as dúas execucións se poidan comparar.

Un pequeno intercambio exitoso tampouco descarta todos os problemas de camiño. Os paquetes grandes poden fallar onde pasan os pequenos, e un filtro que coincide por tamaño ou protocolo pode comportarse distinto baixo carga.

Manteña a aperta de mans como a etapa que se sabe que funciona e avance desde aí. A seguinte proba útil é onde se detén unha petición interna, non un xogo novo de claves e outra rolda de conxecturas.