O handshake de WireGuard funciona, o servizo non

O handshake complétase, o cliente mostra un contador de transferencia recente e, aínda así, unha petición a un servizo do mesmo servidor falla. Esa combinación desconcerta porque o túnel funciona de forma demostrable. O que non se demostrou é a entrega local: o paquete chegou ao host, e o host aínda ten que aceptalo no socket correcto e pasalo a un proceso con permiso para responder. Percorra eses tres puntos de control en orde.

Deteríñase no primeiro que non se cumpra e non engada regras para os demais.

O handshake só demostra o túnel

O handshake de WireGuard establece claves entre pares e autoriza o tráfico para os rangos que cada par enumerou. Non di nada sobre que procesos escoitan no servidor nin sobre se a devasa do host acepta paquetes dirixidos a unha das súas propias direccións.

Esa última distinción é a que máis se pasa por alto: o tráfico cara ao propio host é entrada local, mentres que o tráfico que atravesa o host cara a outro destino é reenvío. Manéxanos cadeas de devasa distintas e axustes distintos. Comprobar a cadea equivocada fai perder unha tarde e devolve contadores que parecen inocentes.

Lea o listener e a ruta

No cliente, confirme que a dirección do túnel do servidor se encamiña cara ao túnel. No servidor, confirme que existe un socket na dirección que usa o cliente e que o proceso que hai detrás é o que pretendía.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

Un listener en 127.0.0.1 nunca responderá a unha petición dirixida a 10.66.0.1, faga o que faga a devasa. Un listener na dirección comodín si o fará, salvo que unha regra o bloquee. A lista de sockets resolve, por tanto, a metade dos casos antes de examinar ningunha regra. O porto e a dirección xuntos deciden se unha petición pode chegar.

Compare a dirección que usa o cliente coa dirección que o servidor posúe realmente na interface do túnel. Unha configuración obsoleta en calquera dos dous lados produce unha petición encamiñada correctamente cara a un par que non ten esa dirección.

Aplique regras para a entrada local, non para o reenvío

Se o paquete chega e o socket existe, a fronteira restante é a política de entrada. Unha regra que permite o reenvío non permite a entrega local, e unha regra limitada a unha interface pode non coincidir co nome da interface do túnel que espera.

Probe cun único porto permitido cara ao servizo previsto en lugar de abrir o host. Despois comprobe a autorización propia da aplicación: unha lista de permitidos, un requisito de conta ou unha vinculación a un nome de host concreto poden rexeitar unha petición que a rede entregou correctamente.

Manteña as comprobacións de certificado. Unha identidade de certificado inesperada é información sobre que host respondeu, non un obstáculo que haxa que saltar. Facer clic a través dela oculta a única pista que identifica o servizo equivocado.

Separe os fallos de nome, tamaño e identidade

Un servizo que funciona por dirección pero falla por nome é un problema de DNS, e a corrección pertence á configuración do resolutor que se envía ao cliente, non á devasa. Un servizo que responde a peticións pequenas pero atasca en respostas maiores apunta ao tamaño de paquete e á MTU, que é unha investigación completamente distinta.

Un erro HTTPS que nomea o host equivocado adoita significar que a petición chegou a outro servizo, a miúdo porque un proxy ou outro listener posúe ese porto. Lea o suxeito do certificado e compáreo co host ao que quería chegar. Esa comparación non custa nada e a miúdo remata a investigación.

Anote que punto de control fallou: socket, regra de entrada ou política da aplicación. Esa soa liña distingue un fallo de rede dunha decisión de autorización. Tamén evita que a seguinte persoa abra portos que nunca foron o problema.