Dante SOCKS en loopback para un servicio HTTPS solo por WireGuard

Vincule un escucha SOCKS dedicado a loopback y permita un único destino TCP. Mantenga separados el origen saliente de Dante, la ruta del núcleo, el DNS y la política de pérdida del túnel.

Este manual da a una aplicación consciente del proxy acceso a una ruta WireGuard existente sin publicar un puerto de proxy en el servidor VPN ni en internet. El demonio SOCKS proporciona la interfaz de la aplicación, WireGuard proporciona la ruta IP ya aprobada, y ninguno de los dos autentica al usuario por usted. Cada paso siguiente produce algo que puede inspeccionar, y cada uno tiene una reversión: detenga la instancia, elimine la regla o quite la configuración de proxy de la aplicación. Nada de esto cambia la ruta predeterminada del host.

El ejemplo supone que Dante 1.4.x está instalado como una instancia dedicada y gestionada en una estación de trabajo Linux de confianza, con la cuenta de servicio y la configuración de registro del paquete dejadas en su sitio. La estación de trabajo posee 10.77.0.2 en su interfaz WireGuard, alcanza 10.60.0.20:443 a través de ese túnel, y el nombre propio del servicio es app.corp.example.

Paso 1: vincule el escucha solo a loopback

Coloque las secciones de red, método y reglas en la configuración activa de la instancia, sustituyendo las direcciones de ejemplo. Todos los ajustes del servidor van antes de los bloques de reglas:

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
}

Esto es un fragmento, no un reemplazo de los ajustes de usuario y registro del paquete. Elija un puerto local sin usar y confirme que esta instancia dedicada no tiene otros escuchas, ni reglas de paso más amplias, ni entradas de encadenamiento superior que cambiarían el contrato. Si una configuración anterior dejó un socks pass sin restricción de destino, elimínelo antes de probar nada.

La reversión de este paso es detener la instancia; el archivo de configuración puede quedarse en disco mientras lo revierte.

Paso 2: escriba dos reglas, no una

La referencia de configuración de Dante da a los dos tipos de regla trabajos distintos. La regla de cliente admite una conexión al escucha de loopback, y su destino es la dirección del propio escucha. La regla SOCKS permite la conexión posterior solicitada hacia el host y el puerto aprobados. Las solicitudes que no coinciden se bloquean de forma predeterminada, y por eso una regla ausente parece idéntica a una ruta rota.

Observe lo que esta configuración deliberadamente no hace: no solicita contraseña SOCKS. Eso encaja con un host local de confianza, y no es autenticación de usuario. Cualquier otro proceso de esa máquina también puede usar loopback. Mantenga la autenticación propia de la aplicación remota y no reutilice esta forma sin autenticación para usuarios locales no confiables ni para un escucha orientado a la LAN.

Paso 3: verifique la ruta desde el origen correcto

external selecciona una dirección de origen saliente; no instala una ruta WireGuard. Consulta de solo lectura para el origen y el destino del ejemplo:

ip -4 route get 10.60.0.20 from 10.77.0.2

Ejecute eso en el espacio de nombres de red real de Dante, no en cualquier shell que tenga abierto. La ruta, la selección de par de WireGuard, el permiso del lado remoto y el camino de vuelta tienen que encajar con esa dirección de origen. Una consulta correcta es necesaria y no suficiente, porque no dice nada sobre si el extremo lejano acepta la solicitud.

Resista la tentación de añadir una ruta predeterminada para que la consulta funcione. El puerto de proxy existe solo en esta estación de trabajo; cambiar la ruta predeterminada del host para crearlo invierte todo el diseño.

Paso 4: pruebe con la identidad prevista

Después de que el propietario valide la configuración instalada e inicie la instancia mediante su gestor de servicios, una solicitud ilustrativa es:

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

Con socks5h, Dante realiza la resolución de destino, pero Dante se ejecuta en esta estación de trabajo, así que el ajuste no envía DNS al extremo lejano del túnel por sí solo. El resolutor aprobado que usa Dante debe devolver la dirección permitida para ese nombre. La lista vacía de sin-proxy impide que una excepción heredada omita SOCKS en silencio.

Conserve la validación del nombre de host y del certificado HTTPS en la prueba, luego inspeccione el escucha real y confirme las dos mitades del contrato: la solicitud permitida tiene éxito y un destino excluido falla. Verifique también que los comandos de reenvío no admitidos sigan denegados, porque este fragmento permite el comando SOCKS CONNECT sobre TCP y nada parecido a un túnel UDP general o de todo el dispositivo.

Paso 5: decida qué pasa cuando cae el túnel

Pruebe la pérdida del túnel y el reinicio de la instancia antes de llamar a esto producción. Un supervisor que inicia Dante después de WireGuard no crea enrutamiento fail-closed, ni tampoco crea DNS fail-closed; ambos deben imponerse a través del propietario de la red. Observe qué hace la aplicación cuando el túnel está caído: un error limpio es un buen resultado, una caída silenciosa a un resolutor público no lo es.

Coordine las actualizaciones si la dirección del túnel vinculada cambia, porque external está fijada a ella. Cuando el arreglo ya no sea necesario, retire esta instancia y la configuración de proxy de la aplicación juntas, y deje la ruta WireGuard a quien la posea.

Artículos relacionados