Como construír unha proba de WireGuard con dous pares que demostra un só camiño

Unha proba de WireGuard que leva unha ruta por defecto, un prefixo LAN, DNS e unha excepción de devasas non pode dicirche cal delas se rompeu. Redúcea a dous pares, un par de enderezos e un só servizo permitido, e o fallo non terá onde esconderse. A base aburrida é o diagnóstico. Constrúea primeiro; leva quince minutos e aforra a tarde que doutro xeito pasarías adiviñando.

O que demostra a base é máis estreito do que a maioría da xente espera. Demostra que dúas identidades coinciden, que UDP chega ao porto de escoita e que un destino permitido transporta unha petición. O reenvío, o NAT, as rutas LAN e o DNS son funcións separadas que se engaden despois, unha a unha.

Chaves, enderezos e o único endpoint

Xera un par de chaves en cada sistema e move entre eles só as metades públicas. wg genkey | tee privatekey | wg pubkey > publickey é a orde documentada dunha soa liña, e deixa a chave privada nun ficheiro que despois podes protexer. Escolle enderezos de túnel dun rango que non apareza en ningunha outra configuración túa, como 10.99.0.1/24 e 10.99.0.2/24. Anota que enderezo pertence a que máquina, porque cada comprobación posterior depende desa correspondencia.

As chaves privadas nunca viaxan. Se unha proba precisa unha copiada ao outro lado, a proba xa saíu mal. Cando os dous sistemas están detrás de NAT, polo menos un necesita un porto UDP accesible mentres o outro leva un Endpoint que apunta a el, e o enderezo público e o porto pertencen ás túas notas, non ás túas suposicións sobre o 51820.

Un reenvío de porto que asigna un porto externo distinto funciona ben sempre que o Endpoint coincida con el. As discrepancias aquí producen silencio en lugar de erros, e por iso paga a pena comprobalas sobre o papel antes de depurar sobre o cable.

Os campos que pertencen a wg e os que non

O conxunto de campos básicos é pequeno: PrivateKey e ListenPort baixo Interface, PublicKey, AllowedIPs e Endpoint baixo Peer. Address e DNS pertencen a wg-quick e non a wg mesmo, e esa distinción morde no momento en que a mesma configuración pasa a outra ferramenta.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs leva dúas tarefas á vez. Selecciona que destinos entran no túnel, e autoriza o par a usar eses enderezos de orixe á chegada. Por iso a entrada espello do outro lado ten que nomear exactamente o enderezo do teu túnel; un /32 para o par equivocado lese como un problema de encamiñamento e compórtase como un de autorización. O inicio rápido de WireGuard mostra a mesma forma de dous pares coa redacción canónica se queres comparar nomes de campos.

Ler o handshake en lugar da icona

Levanta a interface a través do que a posúa e despois le o estado en lugar dunha luz de estado. wg show imprime o último handshake por par xunto cos contadores de bytes, e un handshake nos últimos minutos significa que as chaves, o endpoint e a ruta UDP funcionan todos. Un contador que só sobe nunha dirección é a súa propia resposta, e non é o mesmo fallo que un handshake que nunca ocorre.

Os dous fallos implican investigacións distintas. A ausencia total de handshake apunta a unha discrepancia de chaves, un Endpoint equivocado, UDP bloqueado ou unha devasas que descarta o propio handshake. Un handshake que ten éxito mentres os datos non van a ningures apunta a AllowedIPs, a un servizo que non escoita no enderezo do túnel ou a unha devasas do anfitrión que acepta o porto para a LAN pero non para a interface do túnel. Son metades distintas do sistema, e a base séparaas antes de que comeces a cambiar regras.

Demostrar un servizo permitido e despois o contrario

Fai unha petición ao enderezo de túnel do outro par nun servizo que debe responder, e escolle algo mellor que ping. Unha resposta ICMP ausente pode ser filtrado do anfitrión e non unha falla do túnel, así que un ping silencioso non demostra ningunha dirección. Unha conexión TCP a un porto que sabes aberto, ou unha petición que devolve datos, dache unha resposta que podes interpretar.

Executa a dirección inversa como unha proba separada co seu propio resultado, porque as dúas direccións teñen entradas separadas de devasas e AllowedIPs e poden fallar de xeito independente. Se o handshake funciona e a petición non, o problema está na ruta de datos e non no túnel: AllowedIPs, o servizo que escoita ou unha devasas do anfitrión. Arranxa iso antes de engadir reenvío, NAT ou DNS, ou pasarás a tarde depurando unha función que nunca tivo a culpa.

Manter a base como referencia

Garda a topoloxía que funciona e a fonte do perfil nun lugar desde o que poidas restaurar, e manténs fóra de calquera directorio que se sincronice cun servizo público. Despois engade unha función á vez, repetindo a petición orixinal despois de cada unha: reenvío, NAT, unha ruta LAN e só despois DNS. Cada adición que rompe a proba agora é identificable, porque nada máis se moveu.

Unha base que só pon unha icona verde non che dixo nada sobre que adición causou o seguinte fallo. Mantén o único camiño permitido funcionando como referencia, e cada cambio posterior mídese contra el.