Dante SOCKS auf Loopback für einen HTTPS-Dienst nur über WireGuard

Binden Sie einen dedizierten SOCKS-Listener an Loopback und erlauben Sie genau ein TCP-Ziel. Halten Sie Dantes ausgehende Quelle, Kernel-Route, DNS und Tunnelverlust-Richtlinie getrennt.

Dieses Runbook verschafft einer proxybewussten Anwendung Zugang zu einem bestehenden WireGuard-Pfad, ohne einen Proxy-Port auf dem VPN-Server oder im Internet zu veröffentlichen. Der SOCKS-Daemon liefert die Anwendungsschnittstelle, WireGuard liefert den bereits freigegebenen IP-Pfad, und keiner von beiden authentifiziert den Benutzer für Sie. Jeder Schritt unten erzeugt etwas, das Sie prüfen können, und jeder hat ein Rollback: Instanz stoppen, Regel entfernen oder die Proxy-Einstellung der Anwendung zurücknehmen. Nichts hier ändert die Standardroute des Hosts.

Das Beispiel setzt voraus, dass Dante 1.4.x als dedizierte, verwaltete Instanz auf einer vertrauenswürdigen Linux-Workstation installiert ist und das paketseitige Dienstkonto sowie die Logging-Konfiguration an ihrem Platz bleiben. Die Workstation besitzt 10.77.0.2 auf ihrer WireGuard-Schnittstelle, erreicht 10.60.0.20:443 durch diesen Tunnel, und der eigentliche Name des Dienstes lautet app.corp.example.

Schritt 1: den Listener nur an Loopback binden

Setzen Sie die Abschnitte für Netzwerk, Methode und Regeln in die aktive Konfiguration der Instanz ein und ersetzen Sie die Beispieladressen. Alle Servereinstellungen stehen vor den Regelblöcken:

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
}

Dies ist ein Fragment, kein Ersatz für die Benutzer- und Logging-Einstellungen des Pakets. Wählen Sie einen unbenutzten lokalen Port und bestätigen Sie, dass diese dedizierte Instanz keine weiteren Listener, keine breiteren Pass-Regeln und keine Upstream-Chaining-Einträge hat, die den Vertrag ändern würden. Wenn eine frühere Konfiguration eine socks pass ohne Zielbeschränkung hinterlassen hat, entfernen Sie sie, bevor Sie irgendetwas testen.

Das Rollback für diesen Schritt ist das Stoppen der Instanz; die Konfigurationsdatei kann auf der Platte bleiben, während Sie sie zurücknehmen.

Schritt 2: zwei Regeln schreiben, nicht eine

Dantes Konfigurationsreferenz gibt den beiden Regeltypen unterschiedliche Aufgaben. Die Client-Regel lässt eine Verbindung zum Loopback-Listener zu, und ihr Ziel ist die Listener-Adresse selbst. Die SOCKS-Regel erlaubt die angeforderte Weiterverbindung zum freigegebenen Host und Port. Nicht passende Anfragen werden standardmäßig blockiert, deshalb sieht eine fehlende Regel genauso aus wie eine kaputte Route.

Beachten Sie, was diese Konfiguration bewusst nicht tut: Sie fordert kein SOCKS-Passwort an. Das passt zu einem vertrauenswürdigen lokalen Host und ist keine Benutzerauthentifizierung. Jeder andere Prozess auf dieser Maschine kann Loopback ebenfalls nutzen. Behalten Sie die eigene Authentifizierung der entfernten Anwendung bei, und verwenden Sie diese unauthentifizierte Form nicht für nicht vertrauenswürdige lokale Benutzer oder einen LAN-zugewandten Listener.

Schritt 3: die Route von der richtigen Quelle prüfen

external wählt eine ausgehende Quelladresse; es installiert keine WireGuard-Route. Schreibgeschützte Abfrage für Beispielquelle und -ziel:

ip -4 route get 10.60.0.20 from 10.77.0.2

Führen Sie das im tatsächlichen Netzwerk-Namespace von Dante aus, nicht in irgendeiner zufällig offenen Shell. Die Route, die Auswahl des WireGuard-Peers, die Berechtigung auf der Gegenseite und der Rückweg müssen alle zu dieser Quelladresse passen. Eine erfolgreiche Abfrage ist notwendig und nicht ausreichend, denn sie sagt nichts darüber aus, ob das andere Ende die Anfrage annimmt.

Widerstehen Sie der Versuchung, eine Standardroute hinzuzufügen, damit die Abfrage gelingt. Der Proxy-Port existiert nur auf dieser Workstation; die Standardroute des Hosts zu ändern, um ihn zu schaffen, kehrt das gesamte Design um.

Schritt 4: mit der vorgesehenen Identität testen

Nachdem der Eigentümer die installierte Konfiguration validiert und die Instanz über ihren Dienstmanager gestartet hat, ist eine beispielhafte Anfrage:

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

Mit socks5h übernimmt Dante die Zielauflösung, aber Dante läuft auf dieser Workstation, daher sendet die Einstellung DNS nicht von selbst an das andere Tunnelende. Der freigegebene Resolver, den Dante verwendet, muss die erlaubte Adresse für diesen Namen zurückgeben. Die leere No-Proxy-Liste verhindert, dass eine geerbte Ausnahme SOCKS still umgeht.

Behalten Sie die HTTPS-Hostnamen- und Zertifikatsprüfung im Test bei, prüfen Sie dann den tatsächlichen Listener und bestätigen Sie beide Hälften des Vertrags: Die erlaubte Anfrage gelingt und ein ausgeschlossenes Ziel schlägt fehl. Prüfen Sie außerdem, dass nicht unterstützte Weiterleitungskommandos verweigert bleiben, denn dieses Fragment erlaubt das SOCKS-CONNECT-Kommando über TCP und nichts, was einem allgemeinen UDP- oder Ganzgerät-Tunnel ähnelt.

Schritt 5: entscheiden, was beim Ausfall des Tunnels passiert

Testen Sie Tunnelverlust und Instanzneustart, bevor Sie dies Produktion nennen. Ein Supervisor, der Dante nach WireGuard startet, erzeugt kein fail-closed Routing und auch kein fail-closed DNS; beides muss über den Netzwerkeigentümer durchgesetzt werden. Beobachten Sie, was die Anwendung tut, wenn der Tunnel down ist: ein sauberer Fehler ist ein gutes Ergebnis, ein stiller Rückfall auf einen öffentlichen Resolver nicht.

Koordinieren Sie Aktualisierungen, wenn sich die gebundene Tunneladresse ändert, denn external ist daran festgemacht. Wenn die Anordnung nicht mehr gebraucht wird, ziehen Sie diese Instanz und die Proxy-Einstellung der Anwendung gemeinsam zurück und überlassen Sie den WireGuard-Pfad demjenigen, dem er gehört.

Ähnliche Artikel