Dante SOCKS a loopback per a un servei HTTPS només per WireGuard

Enllaceu un escoltador SOCKS dedicat a loopback i permeteu una destinació TCP. Manteniu separats l'origen sortint de Dante, la ruta del nucli, el DNS i la política de pèrdua del túnel.

Aquest manual dona a una aplicació conscient del proxy accés a una ruta WireGuard existent sense publicar cap port de proxy al servidor VPN ni a internet. El dimoni SOCKS proporciona la interfície de l'aplicació, WireGuard proporciona la ruta IP ja aprovada, i cap dels dos no autentica l'usuari per vosaltres. Cada pas següent produeix alguna cosa que podeu inspeccionar, i cada un té un retrocés: atureu la instància, traieu la regla o traieu la configuració de proxy de l'aplicació. Res d'aquí no canvia la ruta per defecte de l'amfitrió.

L'exemple suposa Dante 1.4.x instal·lat com a instància dedicada i gestionada en una estació de treball Linux de confiança, amb el compte de servei i la configuració de registre del paquet deixats al seu lloc. L'estació de treball posseeix 10.77.0.2 a la seva interfície WireGuard, arriba a 10.60.0.20:443 a través d'aquest túnel, i el nom propi del servei és app.corp.example.

Pas 1: enllaceu l'escoltador només a loopback

Poseu les seccions de xarxa, mètode i regles a la configuració activa de la instància, substituint les adreces d'exemple. Tots els paràmetres del servidor van abans dels blocs de regles:

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
}

Això és un fragment, no un substitut dels paràmetres d'usuari i de registre del paquet. Trieu un port local no utilitzat i confirmeu que aquesta instància dedicada no té altres escoltadors, ni regles de pas més àmplies, ni entrades d'encadenament superior que canviarien el contracte. Si una configuració anterior va deixar un socks pass sense restricció de destinació, traieu-lo abans de provar res.

El retrocés d'aquest pas és aturar la instància; el fitxer de configuració pot quedar-se al disc mentre el revertiu.

Pas 2: escriviu dues regles, no una

La referència de configuració de Dante dona feines diferents als dos tipus de regla. La regla de client admet una connexió a l'escoltador de loopback, i la seva destinació és l'adreça de l'escoltador mateix. La regla SOCKS permet la connexió subsegüent sol·licitada cap a l'amfitrió i el port aprovats. Les sol·licituds no coincidents es bloquegen per defecte, i per això una regla absent sembla idèntica a una ruta trencada.

Fixeu-vos en què no fa deliberadament aquesta configuració: no demana cap contrasenya SOCKS. Això encaixa amb un amfitrió local de confiança, i no és autenticació d'usuari. Qualsevol altre procés d'aquella màquina també pot usar loopback. Manteniu l'autenticació pròpia de l'aplicació remota i no reutilitzeu aquesta forma no autenticada per a usuaris locals no confiables ni per a un escoltador orientat a la LAN.

Pas 3: verifiqueu la ruta des de l'origen correcte

external selecciona una adreça d'origen sortint; no instal·la cap ruta WireGuard. Consulta de només lectura per a l'origen i la destinació de l'exemple:

ip -4 route get 10.60.0.20 from 10.77.0.2

Executeu-ho a l'espai de noms de xarxa real de Dante, no a qualsevol shell que tingueu obert. La ruta, la selecció de parell de WireGuard, el permís del costat remot i el camí de tornada han d'encaixar amb aquesta adreça d'origen. Una consulta correcta és necessària i no suficient, perquè no diu res sobre si l'extrem llunyà accepta la sol·licitud.

Resistiu la temptació d'afegir una ruta per defecte perquè la consulta surti bé. El port de proxy només existeix en aquesta estació de treball; canviar la ruta per defecte de l'amfitrió per crear-lo inverteix tot el disseny.

Pas 4: proveu amb la identitat prevista

Després que el propietari validi la configuració instal·lada i iniciï la instància mitjançant el seu gestor de serveis, una sol·licitud il·lustrativa és:

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

Amb socks5h, Dante fa la resolució de destinació, però Dante s'executa en aquesta estació de treball, així que el paràmetre no envia el DNS a l'extrem llunyà del túnel per si sol. El resolutor aprovat que fa servir Dante ha de retornar l'adreça permesa per a aquest nom. La llista buida de sense-proxy evita que una excepció heretada salti el SOCKS en silenci.

Conserveu la validació del nom d'amfitrió i del certificat HTTPS a la prova, després inspeccioneu l'escoltador real i confirmeu les dues meitats del contracte: la sol·licitud permesa té èxit i una destinació exclosa falla. Verifiqueu també que les ordres de reenviament no suportades continuen denegades, perquè aquest fragment permet l'ordre SOCKS CONNECT sobre TCP i res semblant a un túnel UDP general o de dispositiu sencer.

Pas 5: decidiu què passa quan cau el túnel

Proveu la pèrdua del túnel i el reinici de la instància abans de qualificar-ho de producció. Un supervisor que inicia Dante després de WireGuard no crea encaminament fail-closed, ni tampoc crea DNS fail-closed; tots dos s'han d'imposar a través del propietari de la xarxa. Observeu què fa l'aplicació quan el túnel està caigut: un error net és un bon resultat, una caiguda silenciosa a un resolutor públic no ho és.

Coordineu les actualitzacions si l'adreça del túnel lligada canvia, perquè external hi està fixada. Quan l'arranjament ja no calgui, retireu aquesta instància i la configuració de proxy de l'aplicació alhora, i deixeu la ruta WireGuard a qui la posseeixi.

Articles relacionats