Dante SOCKS på loopback för en HTTPS-tjänst som bara går via WireGuard

Bind en dedikerad SOCKS-lyssnare till loopback och tillåt en enda TCP-destination. Håll Dantes utgående källa, kärnrutt, DNS och tunnelförlustpolicy åtskilda.

Den här handboken ger en proxy-medveten applikation åtkomst till en befintlig WireGuard-väg utan att publicera en proxyport på VPN-servern eller på internet. SOCKS-daemonen tillhandahåller applikationsgränssnittet, WireGuard tillhandahåller den redan godkända IP-vägen, och ingen av dem autentiserar användaren åt dig. Varje steg nedan producerar något du kan granska, och varje steg har en återställning: stoppa instansen, ta bort regeln eller ta bort applikationens proxyinställning. Ingenting här ändrar värdens standardrutt.

Exemplet förutsätter att Dante 1.4.x är installerat som en dedikerad, hanterad instans på en betrodd Linux-arbetsstation, med paketets tjänstekonto och loggkonfiguration lämnade på plats. Arbetsstationen äger 10.77.0.2 på sitt WireGuard-gränssnitt, når 10.60.0.20:443 genom den tunneln, och tjänstens egentliga namn är app.corp.example.

Steg 1: bind lyssnaren bara till loopback

Lägg in avsnitten för nätverk, metod och regler i instansens aktiva konfiguration och ersätt exempeladresserna. Alla serverinställningar kommer före regelblocken:

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
}

Detta är ett fragment, inte en ersättning för paketets användar- och logginställningar. Välj en oanvänd lokal port och bekräfta att denna dedikerade instans inte har andra lyssnare, inga bredare genompasseringsregler och inga uppströmsposter i kedjan som skulle ändra kontraktet. Om en tidigare konfiguration lämnat en socks pass utan destinationsbegränsning, ta bort den innan du testar något.

Återställningen för detta steg är att stoppa instansen; konfigurationsfilen kan ligga kvar på disken medan du återställer den.

Steg 2: skriv två regler, inte en

Dantes konfigurationsreferens ger de två regeltyperna olika uppgifter. Klientregeln tillåter en anslutning till loopback-lyssnaren, och dess destination är lyssnarens egen adress. SOCKS-regeln tillåter den begärda vidare anslutningen till den godkända värden och porten. Icke-matchande förfrågningar blockeras som standard, och därför ser en saknad regel identisk ut med en trasig rutt.

Notera vad denna konfiguration medvetet inte gör: den begär inget SOCKS-lösenord. Det passar en betrodd lokal värd, och det är inte användarautentisering. Vilken annan process som helst på den maskinen kan också använda loopback. Behåll fjärrapplikationens egen autentisering och återanvänd inte denna oautentiserade form för icke betrodda lokala användare eller en LAN-vänd lyssnare.

Steg 3: verifiera rutten från rätt källa

external väljer en utgående källadress; den installerar ingen WireGuard-rutt. Skrivskyddad sökning för exemplets källa och destination:

ip -4 route get 10.60.0.20 from 10.77.0.2

Kör det i Dantes faktiska nätverksnamnrymd, inte i vilket skal du råkar ha öppet. Rutten, valet av WireGuard-peer, behörigheten på fjärrsidan och returvägen måste alla passa den källadressen. En lyckad sökning är nödvändig och inte tillräcklig, eftersom den inte säger något om huruvida den bortre änden accepterar begäran.

Motstå frestelsen att lägga till en standardrutt så att sökningen lyckas. Proxyporten finns bara på den här arbetsstationen; att ändra värdens standardrutt för att skapa den vänder hela designen upp och ner.

Steg 4: testa med den avsedda identiteten

När ägaren har validerat den installerade konfigurationen och startat instansen via sin tjänstehanterare, är en illustrativ begäran:

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

Med socks5h utför Dante destinationsuppslagningen, men Dante körs på den här arbetsstationen, så inställningen skickar inte DNS till tunnelns bortre ände av sig själv. Den godkända resolver som Dante använder måste returnera den tillåtna adressen för det namnet. Den tomma no-proxy-listan hindrar att ett ärvt undantag tyst kringgår SOCKS.

Behåll HTTPS-värdnamns- och certifikatvalidering i testet, granska sedan den faktiska lyssnaren och bekräfta båda halvorna av kontraktet: den tillåtna begäran lyckas och en utesluten destination misslyckas. Verifiera också att icke-stödda vidarebefordringskommandon fortsatt nekas, eftersom detta fragment tillåter SOCKS CONNECT-kommandot över TCP och ingenting som liknar en allmän UDP- eller helenhetstunnel.

Steg 5: bestäm vad som händer när tunneln fallerar

Testa tunnelförlust och omstart av instansen innan du kallar detta produktion. En övervakare som startar Dante efter WireGuard skapar inte fail-closed-routing och skapar inte heller fail-closed-DNS; båda måste genomdrivas via nätverksägaren. Observera vad applikationen gör när tunneln är nere: ett rent fel är ett bra resultat, ett tyst fall tillbaka till en offentlig resolver är det inte.

Samordna uppdateringar om den bundna tunneladressen ändras, eftersom external är fäst vid den. När arrangemanget inte längre behövs, avveckla denna instans och applikationens proxyinställning tillsammans, och lämna WireGuard-vägen till den som äger den.

Relaterade artiklar