Le regole di risposta UDP di Dante invertono la direzione from/to
Applica le regole di risposta di Dante nella direzione esterno→interno invece di copiare le ipotesi di indirizzo del client in uscita.
Il client è autenticato e l'associazione UDP è consentita. Le risposte continuano a fallire. In Dante, esamina la direzione della regola che gestisce il traffico di ritorno.
Dante separa i comandi che avviano l'operazione dalla gestione delle risposte:
| Comandi della regola | from | to |
|---|---|---|
connect, bind, udpassociate | Client interno | Destinazione esterna |
bindreply, udpreply | Host esterno | Client interno |
Copiare senza modifiche la restrizione di subnet di un client in entrambe le direzioni può quindi far corrispondere il lato sbagliato nella regola di risposta. Esamina i mittenti esterni e i destinatari interni previsti, non solo se la parola UDP compare in una regola pass.
L'autenticazione ha un confine correlato. Il servizio esterno che risponde a un datagramma UDP non è un client SOCKS in grado di completare lo scambio nome utente/password. La documentazione di Dante spiega che le operazioni di risposta derivano da una precedente associazione BIND o UDP del client; autentica quell'operazione iniziale e applica la politica appropriata per le risposte associate.
Ciò non giustifica traffico in ingresso non richiesto e illimitato. L'associazione UDP, la politica di destinazione, l'indirizzo del relay e il percorso del firewall contano ancora. Né abilitare bindreply trasforma l'associazione UDP in un servizio generico di port forwarding pubblico.
Tieni visibili separatamente lo scambio SOCKS lato client e l'effettivo percorso di ritorno UDP. Un accesso TCP riuscito non verifica né la direzione degli indirizzi nell'ACL delle risposte né la raggiungibilità dell'endpoint del relay UDP.