Dante SOCKS på loopback for en HTTPS-tjeneste som bare går over WireGuard

Denne kjøreboken gir en proxybevisst applikasjon tilgang til en eksisterende WireGuard-vei uten å publisere en proxyport på VPN-serveren eller på internett. SOCKS-demonen leverer applikasjonsgrensesnittet, WireGuard leverer den allerede godkjente IP-veien, og ingen av dem autentiserer brukeren for deg. Hvert trinn nedenfor produserer noe du kan inspisere, og hvert har en tilbakerulling: stopp instansen, fjern regelen eller fjern applikasjonens proxyinnstilling. Ingenting her endrer vertens standardrute.

Eksempelet forutsetter at Dante 1.4.x er installert som en dedikert, administrert instans på en klarert Linux-arbeidsstasjon, med pakkens tjenestekonto og loggkonfigurasjon latt på plass. Arbeidsstasjonen eier 10.77.0.2 på WireGuard-grensesnittet sitt, når 10.60.0.20:443 gjennom den tunnelen, og tjenestens egentlige navn er app.corp.example.

Trinn 1: bind lytteren bare til loopback

Sett inn avsnittene for nettverk, metode og regler i instansens aktive konfigurasjon, og erstatt eksempeladressene. Alle serverinnstillinger 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 bruker- og logginnstillinger. Velg en ubrukt lokal port, og bekreft at denne dedikerte instansen ikke har andre lyttere, ingen bredere gjennomløpsregler og ingen oppstrøms kjedeposter som ville endre kontrakten. Hvis en tidligere konfigurasjon har latt en socks pass stå uten destinasjonsbegrensning, fjern den før du tester noe.

Tilbakerullingen for dette trinnet er å stoppe instansen; konfigurasjonsfilen kan bli liggende på disken mens du ruller tilbake.

Trinn 2: skriv to regler, ikke én

Dantes konfigurasjonsreferanse gir de to regeltypene forskjellige oppgaver. Klientregelen tillater en tilkobling til loopback-lytteren, og destinasjonen er lytterens egen adresse. SOCKS-regelen tillater den forespurte videre tilkoblingen til den godkjente verten og porten. Ikke-matchende forespørsler blokkeres som standard, og derfor ser en manglende regel identisk ut med en brutt rute.

Legg merke til hva denne konfigurasjonen bevisst ikke gjør: den ber ikke om noe SOCKS-passord. Det passer for en klarert lokal vert, og det er ikke brukerautentisering. Enhver annen prosess på den maskinen kan også bruke loopback. Behold den eksterne applikasjonens egen autentisering, og ikke gjenbruk denne uautentiserte formen for ikke-klarerte lokale brukere eller en LAN-vendt lytter.

Trinn 3: verifiser ruten fra riktig kilde

external velger en utgående kildeadresse; den installerer ikke en WireGuard-rute. Skrivebeskyttet oppslag for eksempelets kilde og destinasjon:

ip -4 route get 10.60.0.20 from 10.77.0.2

Kjør det i Dantes faktiske nettverksnavnerom, ikke i hvilken som helst skall du tilfeldigvis har åpent. Ruten, valget av WireGuard-peer, tillatelsen på fjernsiden og returveien må alle passe til den kildeadressen. Et vellykket oppslag er nødvendig og ikke tilstrekkelig, fordi det ikke sier noe om hvorvidt den fjerne enden godtar forespørselen.

Motstå fristelsen til å legge til en standardrute slik at oppslaget lykkes. Proxyporten finnes bare på denne arbeidsstasjonen; å endre vertens standardrute for å lage den snur hele designet på hodet.

Trinn 4: test med den tiltenkte identiteten

Etter at eieren har validert den installerte konfigurasjonen og startet instansen via tjenestebehandleren sin, er en illustrerende forespørsel:

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

Med socks5h utfører Dante destinasjonsoppslaget, men Dante kjører på denne arbeidsstasjonen, så innstillingen sender ikke DNS til den fjerne enden av tunnelen av seg selv. Den godkjente resolverserveren som Dante bruker, må returnere den tillatte adressen for det navnet. Den tomme no-proxy-listen hindrer at et arvet unntak stille omgår SOCKS.

Behold HTTPS-vertsnavn og sertifikatvalidering i testen, og inspiser deretter den faktiske lytteren og bekreft begge halvdelene av kontrakten: den tillatte forespørselen lykkes, og en utelukket destinasjon feiler. Bekreft også at ikke-støttede videresendingskommandoer fortsatt avvises, fordi dette fragmentet tillater SOCKS CONNECT-kommandoen over TCP og ingenting som ligner en generell UDP- eller helenhetstunnel.

Trinn 5: avgjør hva som skjer når tunnelen faller

Test tunneltap og omstart av instansen før du kaller dette produksjon. En supervisor som starter Dante etter WireGuard, lager ikke fail-closed ruting, og den lager heller ikke fail-closed DNS; begge må håndheves gjennom nettverkseieren. Se hva applikasjonen gjør når tunnelen er nede: en ren feil er et godt resultat, et stille fall tilbake til en offentlig resolverserver er det ikke.

Koordiner oppdateringer hvis den bundne tunneladressen endres, fordi external er festet til den. Når ordningen ikke lenger er nødvendig, avvikle denne instansen og applikasjonens proxyinnstilling sammen, og overlat WireGuard-veien til den som eier den.