Dante SOCKS en loopback para un servizo HTTPS só por WireGuard

Este manual dálle a unha aplicación consciente do proxy acceso a unha ruta WireGuard existente sen publicar un porto de proxy no servidor VPN nin en internet. O daemon SOCKS fornece a interface da aplicación, WireGuard fornece a ruta IP xa aprobada, e ningún dos dous autentica o usuario por vostede. Cada paso seguinte produce algo que pode inspeccionar, e cada un ten unha reversión: deteña a instancia, elimine a regra ou quite a configuración de proxy da aplicación. Nada aquí cambia a ruta predeterminada do host.

O exemplo supón que Dante 1.4.x está instalado como unha instancia dedicada e xestionada nunha estación de traballo Linux de confianza, coa conta de servizo e a configuración de rexistro do paquete deixadas no seu sitio. A estación de traballo posúe 10.77.0.2 na súa interface WireGuard, alcanza 10.60.0.20:443 a través dese túnel, e o nome propio do servizo é app.corp.example.

Paso 1: vincule o escoitador só a loopback

Pon as seccións de rede, método e regras na configuración activa da instancia, substituíndo os enderezos de exemplo. Todos os axustes do servidor van antes dos bloques 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 é un fragmento, non un substituto dos axustes de usuario e rexistro do paquete. Escolla un porto local sen usar e confirme que esta instancia dedicada non ten outros escoitadores, nin regras de paso máis amplas, nin entradas de encadeamento superior que cambiarían o contrato. Se unha configuración anterior deixou un socks pass sen restrición de destino, elimíneo antes de probar nada.

A reversión deste paso é deter a instancia; o ficheiro de configuración pode quedar no disco mentres o reverte.

Paso 2: escriba dúas regras, non unha

A referencia de configuración de Dante dá traballos distintos aos dous tipos de regra. A regra de cliente admite unha conexión ao escoitador de loopback, e o seu destino é o enderezo do propio escoitador. A regra SOCKS permite a conexión posterior solicitada cara ao host e o porto aprobados. As solicitudes que non coinciden bloquéanse por defecto, e por iso unha regra ausente parece idéntica a unha ruta rota.

Observe o que esta configuración deliberadamente non fai: non solicita contrasinal SOCKS. Iso encaixa cun host local de confianza, e non é autenticación de usuario. Calquera outro proceso desa máquina tamén pode usar loopback. Manteña a autenticación propia da aplicación remota e non reutilice esta forma sen autenticación para usuarios locais non confiables nin para un escoitador orientado á LAN.

Paso 3: verifique a ruta desde a orixe correcta

external selecciona un enderezo de orixe saínte; non instala unha ruta WireGuard. Consulta de só lectura para a orixe e o destino do exemplo:

ip -4 route get 10.60.0.20 from 10.77.0.2

Executa iso no espazo de nomes de rede real de Dante, non en calquera shell que teña aberto. A ruta, a selección de par de WireGuard, o permiso do lado remoto e o camiño de volta teñen que encaixar con ese enderezo de orixe. Unha consulta correcta é necesaria e non suficiente, porque non di nada sobre se o extremo afastado acepta a solicitude.

Resista a tentación de engadir unha ruta predeterminada para que a consulta funcione. O porto de proxy existe só nesta estación de traballo; cambiar a ruta predeterminada do host para crealo invirte todo o deseño.

Paso 4: probe coa identidade prevista

Despois de que o propietario valide a configuración instalada e inicie a instancia mediante o seu xestor de servizos, unha solicitude ilustrativa é:

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

Con socks5h, Dante realiza a resolución de destino, pero Dante execútase nesta estación de traballo, así que o axuste non envía o DNS ao extremo afastado do túnel por si só. O resolutor aprobado que usa Dante debe devolver o enderezo permitido para ese nome. A lista baleira de sen-proxy impide que unha excepción herdada omita SOCKS en silencio.

Conserve a validación do nome de host e do certificado HTTPS na proba, despois inspeccione o escoitador real e confirme as dúas metades do contrato: a solicitude permitida ten éxito e un destino excluído falla. Verifique tamén que os comandos de reenvío non admitidos seguen denegados, porque este fragmento permite o comando SOCKS CONNECT sobre TCP e nada parecido a un túnel UDP xeral ou de todo o dispositivo.

Paso 5: decida que pasa cando cae o túnel

Probe a perda do túnel e o reinicio da instancia antes de chamar a isto produción. Un supervisor que inicia Dante despois de WireGuard non crea encamiñamento fail-closed, nin tampouco crea DNS fail-closed; ambos deben impoñerse a través do propietario da rede. Observe que fai a aplicación cando o túnel está caído: un erro limpo é un bo resultado, unha caída silenciosa a un resolutor público non o é.

Coordine as actualizacións se o enderezo do túnel vinculado cambia, porque external está fixado a el. Cando o arranxo xa non sexa necesario, retire esta instancia e a configuración de proxy da aplicación xuntas, e deixe a ruta WireGuard a quen a posúa.