L’encaixada de mans de WireGuard té èxit, però no torna cap resposta

Les encaixades de mans recents són una bona notícia i una afirmació molt més petita que la frase que la gent vol escriure. Els parells han intercanviat missatges d’encaixada de mans autenticats. Un paquet d’aplicació encara ha d’arribar a la seva destinació interna i tornar.

Aquest buit entre un pla de control sa i un pla de dades silenciós és tot el tema d’aquí. Dues lectures dels mateixos comptadors us diuen de quin costat sou.

L’encaixada de mans demostra claus, no lliurament

L’encaixada de mans de WireGuard és un acord de claus amb autenticació. Té èxit tan aviat com els parells es poden abastar i tenen claus vàlides. L’encaminament, la política del tallafoc i la destinació mateixa són preguntes que l’encaixada de mans no fa mai.

Així, un túnel pot estar perfectament establit mentre cada paquet a dins seu es descarta. Un paquet intern mal encaminat i una resposta que pren un altre camí es veuen igual des del client.

Una sola adreça interna és tota la prova

Trieu una destinació i quedeu-vos-hi. L’adreça de túnel del propi parell és el cas més fàcil, i un equip darrere del parell afegeix exactament un salt. Alternar entre ells sense anotar el canvi produeix resultats que ningú no pot comparar.

Després mireu la ruta que tria el client. Una ruta local més específica pot enviar el paquet a un altre lloc abans que es consulti WireGuard, cosa que passa sempre que la LAN de casa se solapa amb el rang remot.

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

Una adreça que es resol a la interfície física ja ha respost la pregunta. El túnel no descarta res. El paquet no hi ha entrat mai.

Els comptadors són proves, no un veredicte

wg show informa dels bytes enviats i rebuts per parell, i els dos números es mouen independentment. Feu una lectura, feu una petició permesa i feu una altra lectura dins del mateix minut.

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

Els enviaments que pugen amb les recepcions planes són la signatura d’una petició sense resposta. No diu si la petició es va filtrar, si la destinació estava caiguda o si la resposta va sortir per una altra ruta. Són tres investigacions que comparteixen un símptoma. Separeu-les abans de canviar cap configuració.

Un nombre fix de bytes tampoc no és un llindar d’èxit. Els valors dels comptadors segueixen el trànsit, i tractar un sol número com a prova de salut produeix disbarats amb molta confiança.

El parell comprova ell mateix el paquet de tornada

El parell remot accepta un paquet intern només quan l’origen cau dins del seu allowedips. Una ruta que existeixi al remitent no n’hi ha prou. Una entrada d’origen absent al receptor descarta el trànsit de tornada en silenci.

Els tallafocs de l’equip seuen darrere d’aquesta comprovació. Una regla de reenviament que permet la interfície del túnel però no la subxarxa interna accepta l’encaixada de mans i rebutja el paquet. Des del costat del client això sembla exactament un parell mort. Un equip amb dues interfícies també pot respondre des de l’origen equivocat, i llavors el parell descarta la resposta que no s’esperava mai.

Mantingueu l’experiment honest

Provar un perfil d’accés remot des de la mateixa xarxa de casa que ha d’assolir exercita un camí diferent del previst. Passeu-vos a la xarxa externa i anoteu-ne el prefix local, perquè les dues execucions es puguin comparar.

Un petit intercanvi reeixit tampoc no descarta tots els problemes de camí. Els paquets grans poden fallar on passen els petits, i un filtre que coincideix per mida o protocol pot comportar-se diferent sota càrrega.

Mantingueu l’encaixada de mans com l’etapa que se sap que funciona i avanceu des d’aquí. La propera prova útil és on s’atura una petició interna, no un joc nou de claus i una altra ronda d’endevinalles.