Dante SOCKS op loopback vir 'n HTTPS-diens wat net WireGuard gebruik

Hierdie runbook gee aan 'n proxy-bewuste toepassing toegang tot 'n bestaande WireGuard-roete sonder om 'n proxy-poort op die VPN-bediener of die internet te publiseer. Die SOCKS-daemon verskaf die toepassing-koppelvlak, WireGuard verskaf die reeds goedgekeurde IP-roete, en nie een van hulle verifieer die gebruiker namens jou nie. Elke stap hieronder lewer iets wat jy kan inspekteer, en elkeen het 'n terugrol: stop die instansie, verwyder die reël, of verwyder die toepassing se proxy-instelling. Niks hier verander die gasheer se verstekroete nie.

Die voorbeeld aanvaar dat Dante 1.4.x as 'n toegewyde, bestuurde instansie op 'n vertroude Linux-werkstasie geïnstalleer is, met sy pakket-verskafte diensrekening en logkonfigurasie onveranderd gelaat. Die werkstasie besit 10.77.0.2 op sy WireGuard-koppelvlak, bereik 10.60.0.20:443 deur daardie tonnel, en die diens se eie naam is app.corp.example.

Stap 1: bind die luisteraar slegs aan loopback

Plaas die netwerk-, metode- en reelaanlyste in die instansie se aktiewe konfigurasie en vervang die voorbeeldadresse. Alle bedienerinstellings kom voor die reëlblokke:

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 'n fragment, nie 'n vervanging vir die pakket se gebruiker- en loginstellings nie. Kies 'n ongebruikte plaaslike poort en bevestig dat hierdie toegewyde instansie geen ander luisteraars, geen wyer deurlaatreëls en geen opstroom-kettinginskrywings het wat die kontrak sou verander nie. As 'n vorige konfigurasie 'n socks pass sonder 'n bestemmingsbeperking gelaat het, verwyder dit voordat jy enigiets toets.

Die terugrol vir hierdie stap is om die instansie te stop; die konfigurasielêer kan op die skyf bly terwyl jy dit terugrol.

Stap 2: skryf twee reëls, nie een nie

Dante se konfigurasieverwysing gee die twee reëltipes verskillende take. Die kliëntreël laat 'n verbinding na die loopback-luisteraar toe, en sy bestemming is die luisteraaradres self. Die SOCKS-reël laat die versoekte verdere verbinding na die goedgekeurde gasheer en poort toe. Ongepaarde versoeke word by verstek geblokkeer, en daarom lyk 'n ontbrekende reël identies aan 'n stukkende roete.

Let op wat hierdie konfigurasie doelbewus nie doen nie: dit vra geen SOCKS-wagwoord nie. Dit pas by 'n vertroude plaaslike gasheer, en dit is nie gebruiker-verifikasie nie. Enige ander proses op daardie masjien kan ook loopback gebruik. Hou die afgeleë toepassing se eie verifikasie in plek, en moenie hierdie ongeverifieerde vorm hergebruik vir onvertroude plaaslike gebruikers of 'n luisteraar wat na die LAN wys nie.

Stap 3: verifieer die roete vanaf die regte bron

external kies 'n uitgaande bronadres; dit installeer nie 'n WireGuard-roete nie. Lees-alleen-soektog vir die voorbeeldbron en -bestemming:

ip -4 route get 10.60.0.20 from 10.77.0.2

Voer dit in Dante se werklike netwerk-naamruimte uit, nie in watter dop jy ook al oop het nie. Die roete, die WireGuard-ewekniekeuse, die toestemming aan die afgeleë kant en die terugpad moet almal by daardie bronadres pas. 'n Suksesvolle soektog is nodig en nie voldoende nie, want dit sê niks oor of die ander kant die versoek aanvaar nie.

Weerstaan die versoeking om 'n verstekroete by te voeg sodat die soektog slaag. Die proxy-poort bestaan slegs op hierdie werkstasie; om die gasheer se verstekroete te verander om dit te skep, keer die hele ontwerp om.

Stap 4: toets met die bedoelde identiteit

Nadat die eienaar die geïnstalleerde konfigurasie gevalideer en die instansie deur sy diensbestuurder begin het, is 'n voorbeeldversoek:

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

Met socks5h, doen Dante die bestemmingsresolusie, maar Dante loop op hierdie werkstasie, dus die instelling stuur nie vanself DNS na die ander kant van die tonnel nie. Die goedgekeurde oplosser wat Dante gebruik, moet die toegelate adres vir daardie naam teruggee. Die leë geen-proxy-lys verhoed dat 'n geërfde uitsondering SOCKS stilweg omseil.

Behou HTTPS-gasheernaam- en sertifikaatvalidering in die toets, inspekteer dan die werklike luisteraar en bevestig albei helftes van die kontrak: die toegelate versoek slaag en 'n uitgeslote bestemming misluk. Verifieer ook dat onondersteunde deurstuurbevele geweier bly, want hierdie fragment laat die SOCKS CONNECT-bevel oor TCP toe en niks wat aan 'n algemene UDP- of heeltoestel-tonnel herinner nie.

Stap 5: besluit wat gebeur wanneer die tonnel val

Toets tonnelverlies en instansie-herbegin voordat jy dit produksie noem. 'n Supervisor wat Dante na WireGuard begin, skep nie fail-closed-roetering nie, en dit skep ook nie fail-closed DNS nie; albei moet deur die netwerkeienaar afgedwing word. Kyk wat die toepassing doen wanneer die tonnel af is: 'n skoon fout is 'n goeie uitkoms, 'n stil terugval na 'n publieke oplosser is nie.

Koordineer opdaterings as die gebinde tonneladres verander, want external is daarop vasgepen. Wanneer die reëling nie meer nodig is nie, trek hierdie instansie en die toepassing se proxy-instelling saam terug, en laat die WireGuard-roete aan wie dit ook al besit.