Dante SOCKS su loopback per un servizio HTTPS solo tramite WireGuard

Questo runbook dà a un'applicazione consapevole del proxy l'accesso a un percorso WireGuard esistente senza pubblicare una porta proxy sul server VPN o su internet. Il demone SOCKS fornisce l'interfaccia dell'applicazione, WireGuard fornisce il percorso IP già approvato, e nessuno dei due autentica l'utente al posto vostro. Ogni passaggio seguente produce qualcosa che potete ispezionare, e ognuno ha un rollback: ferma l'istanza, rimuovi la regola o togli l'impostazione proxy dell'applicazione. Nulla qui cambia la rotta predefinita dell'host.

L'esempio presuppone Dante 1.4.x installato come istanza dedicata e gestita su una stazione di lavoro Linux fidata, con l'account di servizio e la configurazione di logging forniti dal pacchetto lasciati al loro posto. La stazione di lavoro possiede 10.77.0.2 sulla sua interfaccia WireGuard, raggiunge 10.60.0.20:443 attraverso quel tunnel, e il nome proprio del servizio è app.corp.example.

Passaggio 1: collega il listener solo al loopback

Metti le sezioni rete, metodo e regole nella configurazione attiva dell'istanza, sostituendo gli indirizzi di esempio. Tutte le impostazioni del server vanno prima dei blocchi di regole:

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
}

Questo è un frammento, non un sostituto delle impostazioni utente e di logging del pacchetto. Scegli una porta locale inutilizzata e conferma che questa istanza dedicata non abbia altri listener, regole di passaggio più ampie né voci di concatenamento a monte che cambierebbero il contratto. Se una configurazione precedente ha lasciato un socks pass senza vincolo di destinazione, rimuovilo prima di testare qualcosa.

Il rollback di questo passaggio è fermare l'istanza; il file di configurazione può restare su disco mentre lo ripristini.

Passaggio 2: scrivi due regole, non una

La documentazione di configurazione di Dante assegna ai due tipi di regola compiti diversi. La regola client ammette una connessione al listener loopback, e la sua destinazione è l'indirizzo del listener stesso. La regola SOCKS consente la connessione successiva richiesta verso l'host e la porta approvati. Le richieste non corrispondenti vengono bloccate per impostazione predefinita, ed è per questo che una regola mancante sembra identica a una rotta rotta.

Nota ciò che questa configurazione deliberatamente non fa: non richiede alcuna password SOCKS. Ciò si adatta a un host locale fidato, e non è autenticazione utente. Qualsiasi altro processo su quella macchina può usare il loopback. Mantieni l'autenticazione propria dell'applicazione remota e non riutilizzare questa forma non autenticata per utenti locali non fidati o per un listener rivolto alla LAN.

Passaggio 3: verifica la rotta dall'origine giusta

external seleziona un indirizzo di origine in uscita; non installa una rotta WireGuard. Ricerca in sola lettura per l'origine e la destinazione dell'esempio:

ip -4 route get 10.60.0.20 from 10.77.0.2

Esegui questo nel namespace di rete reale di Dante, non in una shell qualsiasi che hai aperto. La rotta, la scelta del peer WireGuard, l'autorizzazione sul lato remoto e il percorso di ritorno devono tutti corrispondere a quell'indirizzo di origine. Una ricerca riuscita è necessaria e non sufficiente, perché non dice nulla sul fatto che l'estremità remota accetti la richiesta.

Resisti alla tentazione di aggiungere una rotta predefinita perché la ricerca riesca. La porta proxy esiste solo su questa stazione di lavoro; cambiare la rotta predefinita dell'host per crearla inverte l'intero progetto.

Passaggio 4: prova con l'identità prevista

Dopo che il proprietario ha convalidato la configurazione installata e avviato l'istanza tramite il suo gestore di servizi, una richiesta illustrativa è:

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

Con socks5h, Dante esegue la risoluzione della destinazione, ma Dante gira su questa stazione di lavoro, quindi l'impostazione non invia da sola il DNS all'estremità remota del tunnel. Il resolver approvato che Dante usa deve restituire l'indirizzo consentito per quel nome. La lista vuota senza proxy impedisce a un'eccezione ereditata di aggirare SOCKS in silenzio.

Conserva la convalida del nome host e del certificato HTTPS nel test, poi ispeziona il listener reale e conferma entrambe le metà del contratto: la richiesta consentita riesce e una destinazione esclusa fallisce. Verifica anche che i comandi di inoltro non supportati restino negati, perché questo frammento consente il comando SOCKS CONNECT su TCP e nulla di simile a un tunnel UDP generale o dell'intero dispositivo.

Passaggio 5: decidi cosa succede quando il tunnel cade

Prova la perdita del tunnel e il riavvio dell'istanza prima di chiamarlo produzione. Un supervisore che avvia Dante dopo WireGuard non crea routing fail-closed, e non crea nemmeno DNS fail-closed; entrambi devono essere imposti tramite il proprietario della rete. Osserva cosa fa l'applicazione quando il tunnel è giù: un errore pulito è un buon risultato, una caduta silenziosa su un resolver pubblico non lo è.

Coordina gli aggiornamenti se l'indirizzo del tunnel associato cambia, perché external è fissato ad esso. Quando l'accorgimento non serve più, ritira questa istanza e l'impostazione proxy dell'applicazione insieme, e lascia il percorso WireGuard a chi lo possiede.