Dante SOCKS pe loopback pentru un serviciu HTTPS doar prin WireGuard

Legați un ascultător SOCKS dedicat la loopback și permiteți o singură destinație TCP. Țineți separat sursa de ieșire a lui Dante, ruta kernelului, DNS-ul și politica de pierdere a tunelului.

Acest ghid oferă unei aplicații conștiente de proxy acces la o cale WireGuard existentă fără a publica un port proxy pe serverul VPN sau pe internet. Daemonul SOCKS furnizează interfața aplicației, WireGuard furnizează calea IP deja aprobată, iar niciunul nu autentifică utilizatorul în locul dumneavoastră. Fiecare pas de mai jos produce ceva ce puteți inspecta, iar fiecare are o revenire: opriți instanța, eliminați regula sau scoateți setarea de proxy a aplicației. Nimic de aici nu schimbă ruta implicită a gazdei.

Exemplul presupune că Dante 1.4.x este instalat ca instanță dedicată și administrată pe o stație de lucru Linux de încredere, cu contul de serviciu și configurația de jurnalizare furnizate de pachet lăsate la locul lor. Stația de lucru deține 10.77.0.2 pe interfața sa WireGuard, ajunge la 10.60.0.20:443 prin acel tunel, iar numele propriu al serviciului este app.corp.example.

Pasul 1: legați ascultătorul doar la loopback

Puneți secțiunile de rețea, metodă și reguli în configurația activă a instanței, înlocuind adresele din exemplu. Toate setările serverului vin înaintea blocurilor de reguli:

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
}

Acesta este un fragment, nu un substitut pentru setările de utilizator și de jurnalizare ale pachetului. Alegeți un port local nefolosit și confirmați că această instanță dedicată nu are alți ascultători, reguli de trecere mai largi și intrări de înlănțuire din amonte care ar schimba contractul. Dacă o configurație anterioară a lăsat un socks pass fără restricție de destinație, eliminați-l înainte de a testa ceva.

Revenirea pentru acest pas este oprirea instanței; fișierul de configurație poate rămâne pe disc în timp ce îl readuceți.

Pasul 2: scrieți două reguli, nu una

Referința de configurare Dante dă celor două tipuri de reguli sarcini diferite. Regula de client admite o conexiune la ascultătorul loopback, iar destinația ei este adresa ascultătorului însuși. Regula SOCKS permite conexiunea ulterioară solicitată către gazda și portul aprobate. Cererile nepotrivite sunt blocate implicit, motiv pentru care o regulă lipsă arată identic cu o rută stricată.

Observați ce nu face în mod deliberat această configurație: nu cere nicio parolă SOCKS. Asta se potrivește unei gazde locale de încredere și nu este autentificare de utilizator. Orice alt proces de pe acea mașină poate folosi la fel de bine loopback. Păstrați autentificarea proprie a aplicației la distanță și nu reutilizați această formă neautentificată pentru utilizatori locali neîncrezători sau pentru un ascultător orientat spre LAN.

Pasul 3: verificați ruta din sursa corectă

external selectează o adresă de sursă de ieșire; nu instalează o rută WireGuard. Interogare doar pentru citire pentru sursa și destinația din exemplu:

ip -4 route get 10.60.0.20 from 10.77.0.2

Rulați asta în spațiul de nume de rețea real al lui Dante, nu în orice shell pe care îl aveți deschis. Ruta, selecția partenerului WireGuard, permisiunea din partea îndepărtată și calea de întoarcere trebuie toate să corespundă acelei adrese de sursă. O interogare reușită este necesară și nu suficientă, pentru că nu spune nimic despre dacă capătul îndepărtat acceptă cererea.

Rezistați tentației de a adăuga o rută implicită pentru ca interogarea să reușească. Portul proxy există doar pe această stație de lucru; schimbarea rutei implicite a gazdei pentru a-l crea întoarce tot designul.

Pasul 4: testați cu identitatea prevăzută

După ce proprietarul validează configurația instalată și pornește instanța prin managerul său de servicii, o cerere ilustrativă este:

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

Cu socks5h, Dante face rezoluția destinației, dar Dante rulează pe această stație de lucru, deci setarea nu trimite singură DNS la capătul îndepărtat al tunelului. Resolverul aprobat pe care îl folosește Dante trebuie să returneze adresa permisă pentru acel nume. Lista goală fără proxy împiedică o excepție moștenită să ocolească în tăcere SOCKS.

Păstrați validarea numelui de gazdă și a certificatului HTTPS în test, apoi inspectați ascultătorul real și confirmați ambele jumătăți ale contractului: cererea permisă reușește, iar o destinație exclusă eșuează. Verificați și că comenzile de redirecționare neacceptate rămân refuzate, pentru că acest fragment permite comanda SOCKS CONNECT peste TCP și nimic asemănător unui tunel UDP general sau al întregului dispozitiv.

Pasul 5: decideți ce se întâmplă când tunelul cade

Testați pierderea tunelului și repornirea instanței înainte de a numi asta producție. Un supervizor care pornește Dante după WireGuard nu creează rutare fail-closed și nu creează nici DNS fail-closed; ambele trebuie impuse prin proprietarul rețelei. Urmăriți ce face aplicația când tunelul este oprit: o eroare curată este un rezultat bun, o cădere silențioasă către un resolver public nu este.

Coordonați actualizările dacă adresa tunelului legată se schimbă, pentru că external este fixată de ea. Când amenajarea nu mai este necesară, retrageți această instanță și setarea de proxy a aplicației împreună, și lăsați calea WireGuard celui care o deține.

Articole similare