Dante SOCKS sur loopback pour un service HTTPS uniquement via WireGuard

Ce guide donne à une application consciente du proxy l'accès à un chemin WireGuard existant sans publier de port proxy sur le serveur VPN ni sur internet. Le démon SOCKS fournit l'interface de l'application, WireGuard fournit le chemin IP déjà approuvé, et ni l'un ni l'autre n'authentifie l'utilisateur à votre place. Chaque étape ci-dessous produit quelque chose que vous pouvez inspecter, et chacune a un retour arrière : arrêtez l'instance, supprimez la règle ou retirez le réglage de proxy de l'application. Rien ici ne modifie la route par défaut de l'hôte.

L'exemple suppose Dante 1.4.x installé comme instance dédiée et gérée sur une station de travail Linux de confiance, le compte de service et la configuration de journalisation fournis par le paquet restant en place. La station de travail possède 10.77.0.2 sur son interface WireGuard, atteint 10.60.0.20:443 à travers ce tunnel, et le nom propre du service est app.corp.example.

Étape 1 : liez l'écouteur à loopback uniquement

Placez les sections réseau, méthode et règles dans la configuration active de l'instance, en remplaçant les adresses d'exemple. Tous les réglages du serveur viennent avant les blocs de règles :

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
}

Ceci est un fragment, pas un remplacement des réglages utilisateur et de journalisation du paquet. Choisissez un port local inutilisé et confirmez que cette instance dédiée n'a pas d'autres écouteurs, pas de règles de passage plus larges et pas d'entrées de chaînage en amont qui changeraient le contrat. Si une configuration précédente a laissé un socks pass sans contrainte de destination, retirez-le avant de tester quoi que ce soit.

Le retour arrière pour cette étape consiste à arrêter l'instance ; le fichier de configuration peut rester sur le disque pendant que vous le rétablissez.

Étape 2 : écrivez deux règles, pas une

La référence de configuration de Dante attribue des tâches différentes aux deux types de règles. La règle client admet une connexion vers l'écouteur loopback, et sa destination est l'adresse de l'écouteur lui-même. La règle SOCKS autorise la connexion ultérieure demandée vers l'hôte et le port approuvés. Les requêtes non concordantes sont bloquées par défaut, ce qui explique qu'une règle manquante ressemble exactement à une route cassée.

Notez ce que cette configuration ne fait délibérément pas : elle ne demande aucun mot de passe SOCKS. Cela convient à un hôte local de confiance, et ce n'est pas une authentification utilisateur. Tout autre processus sur cette machine peut aussi utiliser loopback. Conservez l'authentification propre de l'application distante et ne réutilisez pas cette forme non authentifiée pour des utilisateurs locaux non fiables ou un écouteur orienté LAN.

Étape 3 : vérifiez la route depuis la bonne source

external sélectionne une adresse source sortante ; il n'installe pas de route WireGuard. Consultation en lecture seule pour la source et la destination de l'exemple :

ip -4 route get 10.60.0.20 from 10.77.0.2

Exécutez cela dans l'espace de noms réseau réel de Dante, pas dans un shell que vous avez ouvert par hasard. La route, la sélection du pair WireGuard, l'autorisation côté distant et le chemin de retour doivent tous correspondre à cette adresse source. Une consultation réussie est nécessaire et pas suffisante, car elle ne dit rien sur l'acceptation de la requête par l'extrémité distante.

Résistez à la tentation d'ajouter une route par défaut pour que la consultation réussisse. Le port proxy n'existe que sur cette station de travail ; modifier la route par défaut de l'hôte pour le créer inverse toute la conception.

Étape 4 : testez avec l'identité prévue

Une fois que le propriétaire a validé la configuration installée et démarré l'instance via son gestionnaire de services, une requête illustrative est :

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

Avec socks5h, Dante effectue la résolution de destination, mais Dante s'exécute sur cette station de travail, donc le réglage n'envoie pas le DNS à l'extrémité distante du tunnel par lui-même. Le résolveur approuvé qu'utilise Dante doit renvoyer l'adresse autorisée pour ce nom. La liste vide de non-proxy empêche une exception héritée de contourner SOCKS en silence.

Conservez la validation du nom d'hôte et du certificat HTTPS dans le test, puis inspectez l'écouteur réel et confirmez les deux moitiés du contrat : la requête autorisée réussit et une destination exclue échoue. Vérifiez aussi que les commandes de transfert non prises en charge restent refusées, car ce fragment autorise la commande SOCKS CONNECT sur TCP et rien qui ressemble à un tunnel UDP général ou à un tunnel de l'appareil entier.

Étape 5 : décidez ce qui se passe quand le tunnel tombe

Testez la perte du tunnel et le redémarrage de l'instance avant d'appeler cela de la production. Un superviseur qui démarre Dante après WireGuard ne crée pas de routage fail-closed, et il ne crée pas non plus de DNS fail-closed ; les deux doivent être imposés par le propriétaire du réseau. Observez ce que fait l'application quand le tunnel est coupé : une erreur propre est un bon résultat, un repli silencieux vers un résolveur public ne l'est pas.

Coordonnez les mises à jour si l'adresse du tunnel liée change, car external y est épinglé. Quand le dispositif n'est plus nécessaire, retirez cette instance et le réglage de proxy de l'application ensemble, et laissez le chemin WireGuard à celui qui le possède.