Dante SOCKS på loopback for ei HTTPS-teneste som berre går over WireGuard

Den køyreboka gjev ein proxyviss applikasjon tilgang til ein eksisterande WireGuard-veg utan å publisere ein proxyport på VPN-tenaren eller på internett. SOCKS-dæmonen leverer applikasjonsgrensesnittet, WireGuard leverer den allereie godkjende IP-vegen, og ingen av dei autentiserer brukaren for deg. Kvart steg nedanfor produserer noko du kan inspisere, og kvart har ei tilbakerulling: stogg instansen, fjern regelen eller fjern proxyinnstillinga til applikasjonen. Ingenting her endrar standardruta til verten.

Dømet føreset at Dante 1.4.x er installert som ein dedikert, administrert instans på ein klarert Linux-arbeidsstasjon, med tenestekontoen og loggkonfigurasjonen frå pakken lat på plass. Arbeidsstasjonen eig 10.77.0.2 på WireGuard-grensesnittet sitt, når 10.60.0.20:443 gjennom den tunnelen, og det eigentlege namnet på tenesta er app.corp.example.

Steg 1: bind lyttaren berre til loopback

Set inn avsnitta for nettverk, metode og reglar i den aktive konfigurasjonen til instansen, og byt ut dømeadressene. Alle tenarinnstillingar kjem 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 eit fragment, ikkje ei erstatning for brukar- og logginnstillingane til pakken. Vel ein ubrukt lokal port, og stadfest at denne dedikerte instansen ikkje har andre lyttarar, ingen breiare gjennomløpsreglar og ingen oppstraums kjedepostar som ville endre kontrakten. Viss ein tidlegare konfigurasjon let ein socks pass stå utan destinasjonsavgrensing, fjern han før du testar noko.

Tilbakerullinga for dette steget er å stogge instansen; konfigurasjonsfila kan bli liggjande på disken medan du rullar tilbake.

Steg 2: skriv to reglar, ikkje éin

Dante sin konfigurasjonsreferanse gjev dei to regeltypane ulike oppgåver. Klientregelen tillèt ei tilkopling til loopback-lyttaren, og destinasjonen er adressa til lyttaren sjølv. SOCKS-regelen tillèt den førespurde vidare tilkoplinga til den godkjende verten og porten. Ikkje-matchende førespurnader blir blokkerte som standard, og difor ser ein manglande regel identisk ut med ei broten rute.

Legg merke til kva denne konfigurasjonen medvite ikkje gjer: han ber ikkje om noko SOCKS-passord. Det passar for ein klarert lokal vert, og det er ikkje brukarautentisering. Kvar annan prosess på den maskina kan også bruke loopback. Hald den eigen autentiseringa til den eksterne applikasjonen, og ikkje bruk denne uautentiserte forma på nytt for ikkje-klarerte lokale brukarar eller ein LAN-vend lyttar.

Steg 3: stadfest ruta frå rett kjelde

external vel ein utgåande kjeldadresse; han installerer ikkje ei WireGuard-rute. Skriveverna oppslag for døme-kjelda og -destinasjonen:

ip -4 route get 10.60.0.20 from 10.77.0.2

Køyr det i den faktiske nettverksnamnerommet til Dante, ikkje i eit eller anna skal du tilfeldigvis har ope. Ruta, valet av WireGuard-peer, løyvet på fjernsida og returvegen må alle passe til den kjeldadressa. Eit vellukka oppslag er naudsynt og ikkje tilstrekkeleg, fordi det ikkje seier noko om den fjerne enden godtek førespurnaden.

Motstå freistinga til å leggje til ei standardrute slik at oppslaget lukkast. Proxyporten finst berre på denne arbeidsstasjonen; å endre standardruta til verten for å lage han snur heile designet på hovudet.

Steg 4: test med den tiltenkte identiteten

Etter at eigaren har validert den installerte konfigurasjonen og starta instansen via tenestebehandsamaren sin, er ein illustrerande førespurnad:

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

Med socks5h gjer Dante destinasjonsoppslaget, men Dante køyrer på denne arbeidsstasjonen, så innstillinga sender ikkje DNS til den fjerne enden av tunnelen av seg sjølv. Den godkjende resolvaren som Dante brukar, må returnere den tillatne adressa for det namnet. Den tomme no-proxy-lista hindrar at eit arva unntak stille omgår SOCKS.

Hald HTTPS-vertsnamn og sertifikatvalidering i testen, inspiser så den faktiske lyttaren og stadfest båe halvdelane av kontrakten: den tillatne førespurnaden lukkast, og ein utelukka destinasjon feilar. Stadfest også at ikkje-støtta vidaresendingskommandoar framleis blir avviste, fordi dette fragmentet tillèt SOCKS CONNECT-kommandoen over TCP og ingenting som liknar ein generell UDP- eller heile-eininga-tunnel.

Steg 5: avgjer kva som skjer når tunnelen fell

Test tunneltap og omstart av instansen før du kallar dette produksjon. Ein supervisor som startar Dante etter WireGuard, lagar ikkje fail-closed ruting, og han lagar heller ikkje fail-closed DNS; båe må handhevast gjennom nettverkseigaren. Sjå kva applikasjonen gjer når tunnelen er nede: ein rein feil er eit godt resultat, eit stille fall tilbake til ein offentleg resolvar er det ikkje.

Koordiner oppdateringar viss den bundne tunneladressa endrar seg, fordi external er fest til henne. Når ordninga ikkje lenger er naudsynt, avvikle denne instansen og proxyinnstillinga til applikasjonen saman, og overlat WireGuard-vegen til den som eig han.