Dante SOCKS på loopback til en HTTPS-tjeneste, der kun kører over WireGuard

Denne kørebog giver en proxybevidst applikation adgang til en eksisterende WireGuard-vej uden at udgive en proxyport på VPN-serveren eller på internettet. SOCKS-dæmonen leverer applikationsgrænsefladen, WireGuard leverer den allerede godkendte IP-vej, og ingen af dem godkender brugeren for dig. Hvert trin nedenfor frembringer noget, du kan inspicere, og hvert har en tilbagerulning: stop instansen, fjern reglen, eller fjern applikationens proxyindstilling. Intet her ændrer værtens standardrute.

Eksemplet antager, at Dante 1.4.x er installeret som en dedikeret, administreret instans på en betroet Linux-arbejdsstation, med pakkens servicekonto og logkonfiguration efterladt på plads. Arbejdsstationen ejer 10.77.0.2 på sin WireGuard-grænseflade, når 10.60.0.20:443 gennem den tunnel, og tjenestens egentlige navn er app.corp.example.

Trin 1: bind lytteren kun til loopback

Sæt netværks-, metode- og regelsektionerne ind i instansens aktive konfiguration, og erstat eksempeladresserne. Alle serverindstillinger kommer før regelblokkene:

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
}

Dette er et fragment, ikke en erstatning for pakkens bruger- og logindstillinger. Vælg en ubrugt lokal port, og bekræft at denne dedikerede instans ikke har andre lyttere, ingen bredere gennemløbsregler og ingen upstream-kædeindgange, der ville ændre kontrakten. Hvis en tidligere konfiguration har efterladt en socks pass uden destinationsbegrænsning, skal du fjerne den, før du tester noget.

Tilbagerulningen for dette trin er at stoppe instansen; konfigurationsfilen kan blive liggende på disken, mens du ruller tilbage.

Trin 2: skriv to regler, ikke én

Dantes konfigurationsreference giver de to regeltyper forskellige opgaver. Klientreglen tillader en forbindelse til loopback-lytteren, og dens destination er lytterens egen adresse. SOCKS-reglen tillader den ønskede videre forbindelse til den godkendte vært og port. Ikke-matchende anmodninger blokeres som standard, og derfor ser en manglende regel identisk ud med en brudt rute.

Læg mærke til, hvad denne konfiguration bevidst ikke gør: den beder ikke om en SOCKS-adgangskode. Det passer til en betroet lokal vært, og det er ikke brugergodkendelse. Enhver anden proces på den maskine kan også bruge loopback. Behold den eksterne applikations egen godkendelse, og genbrug ikke denne uautentificerede form til ikke-betroede lokale brugere eller en LAN-vendt lytter.

Trin 3: verificér ruten fra den rigtige kilde

external vælger en udgående kildeadresse; den installerer ikke en WireGuard-rute. Skrivebeskyttet opslag for eksemplets kilde og destination:

ip -4 route get 10.60.0.20 from 10.77.0.2

Kør det i Dantes faktiske netværksnavnerum, ikke i den skal, du tilfældigvis har åben. Ruten, valget af WireGuard-peer, tilladelsen i den fjerne ende og returvejen skal alle passe til den kildeadresse. Et vellykket opslag er nødvendigt og ikke tilstrækkeligt, fordi det intet siger om, hvorvidt den fjerne ende accepterer anmodningen.

Modstå fristelsen til at tilføje en standardrute, så opslaget lykkes. Proxyporten findes kun på denne arbejdsstation; at ændre værtens standardrute for at skabe den vender hele designet på hovedet.

Trin 4: test med den tilsigtede identitet

Når ejeren har valideret den installerede konfiguration og startet instansen via sin service manager, er en illustrativ anmodning:

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

Med socks5h udfører Dante destinationsopløsningen, men Dante kører på denne arbejdsstation, så indstillingen sender ikke selv DNS til den fjerne ende af tunnelen. Den godkendte resolver, som Dante bruger, skal returnere den tilladte adresse for det navn. Den tomme no-proxy-liste forhindrer, at en nedarvet undtagelse stille omgår SOCKS.

Bevar HTTPS-værtsnavn og certifikatvalidering i testen, og undersøg derefter den faktiske lytter og bekræft begge halvdele af kontrakten: den tilladte anmodning lykkes, og en udelukket destination fejler. Bekræft også, at ikke-understøttede videresendelseskommandoer forbliver afvist, fordi dette fragment tillader SOCKS CONNECT-kommandoen over TCP og intet, der ligner en generel UDP- eller helenhedstunnel.

Trin 5: beslut, hvad der sker, når tunnelen falder

Test tab af tunnel og genstart af instansen, før du kalder dette produktion. En supervisor, der starter Dante efter WireGuard, skaber ikke fail-closed routing, og den skaber heller ikke fail-closed DNS; begge skal håndhæves gennem netværksejeren. Se, hvad applikationen gør, når tunnelen er nede: en ren fejl er et godt resultat, et stille fald tilbage til en offentlig resolver er det ikke.

Koordinér opdateringer, hvis den bundne tunneladresse ændres, fordi external er fastgjort til den. Når ordningen ikke længere er nødvendig, skal du afvikle denne instans og applikationens proxyindstilling sammen og overlade WireGuard-vejen til den, der ejer den.