L’handshake de WireGuard funciona però no hi ha internet: ressegueix el paquet

El túnel està aixecat, wg show informa d’un handshake recent, pots fer ping a l’adreça del túnel del servidor i res més enllà no respon. L’instint és regenerar les claus o tornar a compartir la configuració. Això canvia precisament la part del camí que ja està demostrat que funciona.

Un handshake complet diu que els dos iguals coincideixen en les claus, que l’UDP arriba al punt final i que l’encaminament criptogràfic accepta el paquet. No diu res sobre si el paquet pot sortir del servidor després.

Així que segueix un sol paquet en lloc d’endevinar. Hi ha quatre llocs on pot morir, i cadascun deixa un rastre diferent.

Què demostra realment l’handshake

WireGuard és un protocol UDP que estableix una sessió amb un handshake Noise i després xifra els paquets per a un igual. Quan wg show llista un handshake de fa uns segons i un comptador de transferència creixent, el punt final, les claus i la clau pública de l’igual són tots correctes.

El que no demostra és que el teu client enviï trànsit cap a internet a la interfície, que el servidor estigui disposat a reenviar-lo o que una resposta pugui trobar el camí de tornada. Aquestes són decisions d’encaminament del nucli i del tallafocs, i es prenen fora del túnel.

Per això fer ping a l’adreça del túnel del servidor és una prova tan enganyosa. Aquest paquet és adreçat al mateix servidor, així que acaba localment. Mai no necessita reenviament, mai no necessita traducció i mai no necessita una ruta de tornada des d’internet.

AllowedIPs és una decisió d’encaminament

Al client, AllowedIPs fa dues feines. És la taula d’encaminament de clau criptogràfica que decideix quines adreces de destinació s’envien al túnel d’aquest igual, i és la llista d’adreces d’origen que l’igual acceptarà de tu. Si la configuració del client només llista 10.8.0.0/24, les destinacions públiques no entren mai a la interfície i la teva ruta per defecte habitual les porta fora del túnel. Llavors el túnel funciona perfectament i no fa res del que volies.

Mira què ha instal·lat realment el client en lloc del que diu el fitxer de configuració:

wg show wg0 allowed-ips
ip route get 1.1.1.1

La segona ordre és la decisiva. Si la resposta nomena la teva interfície física i la passarel·la habitual, el paquet no s’està tunelitzant i cap canvi al costat del servidor ho arreglarà. Afegeix 0.0.0.0/0 per a IPv4 i ::/0 per a IPv6 per separat; una regla que ho atrapa tot per a una família deixa l’altra al seu camí original, i això és una causa habitual d’un túnel IPv4 que funciona i d’una consulta IPv6 encallada.

On mor el paquet a la passarel·la

Si la ruta és correcta i el paquet continua sense anar enlloc, arriba al servidor i s’atura allà. Quatre comprovacions cobreixen la majoria de passarel·les.

Reenviament. sysctl net.ipv4.ip_forward que retorna 0 és la resposta clàssica, i moltes distribucions encara tenen 0 per defecte. Ha de ser 1, i cal fixar-ho de manera persistent en un fitxer sysctl en lloc d’una ordre que desapareix en reiniciar. El reenviament d’IPv6 és un commutador a part.

La política de filtratge. Una cadena FORWARD amb una política de descart per defecte descartarà el trànsit del túnel mentre permet el trànsit cap al mateix amfitrió, cosa que encaixa exactament amb el símptoma. Llegeix el conjunt de regles viu, no un fitxer desat: nft list ruleset o iptables -S.

Traducció o encaminament. Els clients amb adreces de túnel privades necessiten o bé NAT d’origen a la interfície de sortida del servidor, o bé un prefix encaminat que la xarxa superior sàpiga tornar. Triar entre tots dos segueix el pla d’adreces. Afegir MASQUERADE a una xarxa que ja encamina el teu prefix de tornada és inofensiu però inútil, i ometre-ho on no existeix cap ruta deixa les respostes adreçades a un rang privat no encaminable.

El camí de tornada. En dissenys encaminats, l’encaminador superior necessita una ruta que apunti al teu servidor. La xarxa del proveïdor també ho pot bloquejar: diversos núvols activen una comprovació d’origen i destinació a la instància, que descarta silenciosament els paquets l’origen dels quals no és l’adreça pròpia de la instància fins que es desactiva aquesta comprovació.

El DNS falla d’una manera diferent de l’encaminament

Un paquet a una adreça coneguda i una consulta de nom són fallades separades, i els missatges d’error enganyen en direccions oposades. Si ping 1.1.1.1 funciona i un navegador no pot carregar res, la ruta està bé i la resolució de noms no. Si el ping mateix falla, el DNS és irrellevant i tornes a la secció anterior.

wg-quick pot establir un resolutor a partir de la línia DNS = de la configuració, i systemd-resolved té el seu propi comportament per enllaç. Una VPN que sobreescriu el resolutor amb una adreça només abastable dins del túnel farà fallar cada consulta en el moment que caigui el túnel, cosa que sembla que el túnel trenca internet.

Un ordre que produeix proves

Fes primer la comprovació del costat del client, perquè és una sola ordre i elimina la meitat de les possibilitats. Després confirma si el servidor està pensat per ser una sortida a internet; una passarel·la feta per a accés privat no està trencada quan les destinacions públiques fallen.

Al servidor, mira la interfície mentre envies un ping des del client: tcpdump -ni wg0 icmp hauria de mostrar la petició, i tcpdump -ni eth0 icmp hauria de mostrar-la sortint, traduïda o no. Si apareix a la primera i mai a la segona, l’aturada és local al servidor. Si surt i no torna cap resposta, el problema és més amunt, i això és una altra conversa.

Finalment, fes que l’arreglament sobrevisqui a un reinici. El reenviament pertany a un fitxer sysctl, les regles del tallafocs pertanyen al servei que les carrega, i les rutes del client pertanyen a la configuració que aixeca la interfície en lloc d’un shell que oblidaràs. Torna a connectar-te, repeteix les mateixes dues proves i confirma que els comptadors es mouen.