Dante SOCKS op loopback voor een HTTPS-dienst die alleen via WireGuard loopt

Deze runbook geeft een proxybewuste applicatie toegang tot een bestaand WireGuard-pad zonder een proxy-poort op de VPN-server of op internet te publiceren. De SOCKS-daemon levert de applicatie-interface, WireGuard levert het al goedgekeurde IP-pad, en geen van beide authenticeert de gebruiker voor u. Elke stap hieronder levert iets op dat u kunt inspecteren, en elke stap heeft een terugdraai: stop de instantie, verwijder de regel of haal de proxyinstelling van de applicatie weg. Niets hier verandert de standaardroute van de host.

Het voorbeeld gaat ervan uit dat Dante 1.4.x is geïnstalleerd als een speciale, beheerde instantie op een vertrouwd Linux-werkstation, met het door het pakket geleverde serviceaccount en de logconfiguratie op hun plaats gelaten. Het werkstation bezit 10.77.0.2 op zijn WireGuard-interface, bereikt 10.60.0.20:443 via die tunnel, en de eigenlijke naam van de dienst is app.corp.example.

Stap 1: bind de listener alleen aan loopback

Zet de secties netwerk, methode en regels in de actieve configuratie van de instantie en vervang de voorbeeldadressen. Alle serverinstellingen komen vóór de regelblokken:

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
}

Dit is een fragment, geen vervanging van de gebruikers- en loginstellingen van het pakket. Kies een ongebruikte lokale poort en bevestig dat deze speciale instantie geen andere listeners, geen bredere doorlaatregels en geen upstream-ketenregels heeft die het contract zouden veranderen. Als een eerdere configuratie een socks pass zonder bestemmingsbeperking heeft achtergelaten, verwijder die dan voordat u iets test.

De terugdraai voor deze stap is het stoppen van de instantie; het configuratiebestand kan op schijf blijven staan terwijl u het terugdraait.

Stap 2: schrijf twee regels, niet één

De configuratiereferentie van Dante geeft de twee regeltypen verschillende taken. De clientregel staat een verbinding naar de loopback-listener toe, en de bestemming is het adres van de listener zelf. De SOCKS-regel staat de gevraagde vervolgverbinding naar de goedgekeurde host en poort toe. Niet-passende verzoeken worden standaard geblokkeerd, waardoor een ontbrekende regel identiek lijkt aan een kapotte route.

Let op wat deze configuratie bewust niet doet: zij vraagt geen SOCKS-wachtwoord. Dat past bij een vertrouwde lokale host, en het is geen gebruikersauthenticatie. Elk ander proces op die machine kan loopback ook gebruiken. Houd de eigen authenticatie van de externe applicatie in stand, en hergebruik deze niet-geauthenticeerde vorm niet voor niet-vertrouwde lokale gebruikers of een listener die naar het LAN kijkt.

Stap 3: verifieer de route vanaf de juiste bron

external selecteert een uitgaand bronadres; het installeert geen WireGuard-route. Alleen-lezen opzoeking voor de voorbeeldbron en -bestemming:

ip -4 route get 10.60.0.20 from 10.77.0.2

Voer dat uit in de werkelijke netwerk-naamruimte van Dante, niet in een shell die u toevallig open hebt. De route, de keuze van WireGuard-peer, de toestemming aan de andere kant en de retourweg moeten allemaal bij dat bronadres passen. Een geslaagde opzoeking is noodzakelijk en niet voldoende, want zij zegt niets over de vraag of het verre uiteinde het verzoek accepteert.

Weerstа de verleiding om een standaardroute toe te voegen zodat de opzoeking slaagt. De proxy-poort bestaat alleen op dit werkstation; de standaardroute van de host wijzigen om hem te maken keert het hele ontwerp om.

Stap 4: test met de bedoelde identiteit

Nadat de eigenaar de geïnstalleerde configuratie heeft gevalideerd en de instantie via zijn servicemanager heeft gestart, is een illustratief verzoek:

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

Met socks5h doet Dante de bestemmingsresolutie, maar Dante draait op dit werkstation, dus de instelling stuurt DNS niet vanzelf naar het verre uiteinde van de tunnel. De goedgekeurde resolver die Dante gebruikt, moet het toegestane adres voor die naam teruggeven. De lege no-proxy-lijst voorkomt dat een geërfde uitzondering SOCKS stilzwijgend omzeilt.

Behoud HTTPS-hostnaam- en certificaatvalidatie in de test, inspecteer dan de werkelijke listener en bevestig beide helften van het contract: het toegestane verzoek slaagt en een uitgesloten bestemming faalt. Controleer ook dat niet-ondersteunde doorstuurcommando's geweigerd blijven, want dit fragment staat het SOCKS CONNECT-commando over TCP toe en niets dat op een algemene UDP- of hele-apparaattunnel lijkt.

Stap 5: beslis wat er gebeurt als de tunnel wegvalt

Test tunnelverlies en herstart van de instantie voordat u dit productie noemt. Een supervisor die Dante na WireGuard start, maakt geen fail-closed routing en ook geen fail-closed DNS; beide moeten via de netwerkeigenaar worden afgedwongen. Kijk wat de applicatie doet als de tunnel plat ligt: een schone fout is een goede uitkomst, een stille terugval naar een publieke resolver niet.

Coördineer updates als het gebonden tunneladres verandert, want external is eraan vastgemaakt. Als de opzet niet meer nodig is, trek dan deze instantie en de proxyinstelling van de applicatie samen terug, en laat het WireGuard-pad aan wie het ook bezit.