Dante SOCKS em loopback para um serviço HTTPS apenas por WireGuard

Este guia dá a uma aplicação ciente de proxy acesso a um caminho WireGuard existente sem publicar uma porta de proxy no servidor VPN ou na internet. O daemon SOCKS fornece a interface da aplicação, o WireGuard fornece o caminho IP já aprovado, e nenhum dos dois autentica o utilizador por si. Cada passo abaixo produz algo que pode inspecionar, e cada um tem uma reversão: pare a instância, remova a regra ou retire a definição de proxy da aplicação. Nada aqui altera a rota predefinida do anfitrião.

O exemplo pressupõe que o Dante 1.4.x está instalado como uma instância dedicada e gerida numa estação de trabalho Linux de confiança, com a conta de serviço e a configuração de registo do pacote deixadas no lugar. A estação de trabalho possui 10.77.0.2 na sua interface WireGuard, alcança 10.60.0.20:443 através desse túnel, e o nome próprio do serviço é app.corp.example.

Passo 1: vincule o ouvinte apenas ao loopback

Coloque as secções de rede, método e regras na configuração ativa da instância, substituindo os endereços de exemplo. Todas as definições do servidor vêm antes dos blocos de regras:

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

Isto é um fragmento, não um substituto das definições de utilizador e de registo do pacote. Escolha uma porta local não utilizada e confirme que esta instância dedicada não tem outros ouvintes, nem regras de passagem mais amplas, nem entradas de encadeamento a montante que alterariam o contrato. Se uma configuração anterior deixou um socks pass sem restrição de destino, remova-o antes de testar seja o que for.

A reversão deste passo é parar a instância; o ficheiro de configuração pode ficar no disco enquanto o reverte.

Passo 2: escreva duas regras, não uma

A referência de configuração do Dante dá tarefas diferentes aos dois tipos de regra. A regra de cliente admite uma ligação ao ouvinte de loopback, e o seu destino é o endereço do próprio ouvinte. A regra SOCKS permite a ligação seguinte solicitada ao anfitrião e à porta aprovados. Os pedidos não correspondentes são bloqueados por predefinição, e é por isso que uma regra em falta parece idêntica a uma rota quebrada.

Note o que esta configuração deliberadamente não faz: não pede palavra-passe SOCKS. Isso serve um anfitrião local de confiança, e não é autenticação de utilizador. Qualquer outro processo nessa máquina também pode usar loopback. Mantenha a autenticação própria da aplicação remota e não reutilize esta forma não autenticada para utilizadores locais não confiáveis nem para um ouvinte virado para a LAN.

Passo 3: verifique a rota a partir da origem correta

external seleciona um endereço de origem de saída; não instala uma rota WireGuard. Consulta só de leitura para a origem e o destino do exemplo:

ip -4 route get 10.60.0.20 from 10.77.0.2

Execute isso no espaço de nomes de rede real do Dante, não em qualquer shell que tenha aberto. A rota, a seleção de par WireGuard, a permissão do lado remoto e o caminho de regresso têm de corresponder a esse endereço de origem. Uma consulta bem-sucedida é necessária e não suficiente, porque não diz nada sobre se a extremidade remota aceita o pedido.

Resista à tentação de acrescentar uma rota predefinida para a consulta funcionar. A porta de proxy existe apenas nesta estação de trabalho; alterar a rota predefinida do anfitrião para a criar inverte todo o desenho.

Passo 4: teste com a identidade prevista

Depois de o proprietário validar a configuração instalada e iniciar a instância através do seu gestor de serviços, um pedido ilustrativo é:

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

Com socks5h, o Dante efetua a resolução do destino, mas o Dante corre nesta estação de trabalho, por isso a definição não envia o DNS para a extremidade remota do túnel por si mesma. O resolvedor aprovado que o Dante usa tem de devolver o endereço permitido para esse nome. A lista vazia de sem-proxy impede que uma exceção herdada contorne o SOCKS em silêncio.

Mantenha a validação do nome de anfitrião e do certificado HTTPS no teste, depois inspecione o ouvinte real e confirme as duas metades do contrato: o pedido permitido tem sucesso e um destino excluído falha. Verifique também que os comandos de encaminhamento não suportados continuam negados, porque este fragmento permite o comando SOCKS CONNECT sobre TCP e nada semelhante a um túnel UDP geral ou de todo o dispositivo.

Passo 5: decida o que acontece quando o túnel cai

Teste a perda do túnel e o reinício da instância antes de chamar isto produção. Um supervisor que inicia o Dante depois do WireGuard não cria encaminhamento fail-closed, nem cria DNS fail-closed; ambos têm de ser impostos pelo proprietário da rede. Observe o que a aplicação faz quando o túnel está em baixo: um erro limpo é um bom resultado, uma queda silenciosa para um resolvedor público não é.

Coordene as atualizações se o endereço do túnel vinculado mudar, porque external está fixado a ele. Quando o arranjo deixar de ser necessário, retire esta instância e a definição de proxy da aplicação em conjunto, e deixe o caminho WireGuard a quem o possui.