Passa al contenuto principale

6. Replies (Risposte)

Le informazioni di richiesta SOCKS vengono inviate dal client non appena ha stabilito una connessione al server SOCKS e completato le negoziazioni di autenticazione (Authentication Negotiation). Il server valuta la richiesta e restituisce una risposta formata come segue:

     +----+-----+-------+------+----------+----------+
     |VER | REP |  RSV  | ATYP | BND.ADDR | BND.PORT |
     +----+-----+-------+------+----------+----------+
     | 1  |  1  | X'00' |  1   | Variable |    2     |
     +----+-----+-------+------+----------+----------+

Dove:

  • VER versione del protocollo: X'05'
  • REP campo di risposta (Reply Field):
    • X'00' riuscito (succeeded)
    • X'01' guasto generale del server SOCKS (general SOCKS server failure)
    • X'02' connessione non consentita dal set di regole (connection not allowed by ruleset)
    • X'03' Rete non raggiungibile (Network unreachable)
    • X'04' Host non raggiungibile (Host unreachable)
    • X'05' Connessione rifiutata (Connection refused)
    • X'06' TTL scaduto (TTL expired)
    • X'07' Comando non supportato (Command not supported)
    • X'08' Tipo di indirizzo non supportato (Address type not supported)
    • X'09' to X'FF' non assegnato (unassigned)
  • RSV RISERVATO (RESERVED)
  • ATYP tipo di indirizzo dell'indirizzo seguente
    • IP V4 address: X'01'
    • DOMAINNAME: X'03'
    • IP V6 address: X'04'
  • BND.ADDR indirizzo vincolato al server (Server Bound Address)
  • BND.PORT porta vincolata al server nell'ordine degli ottetti di rete (Server Bound Port in Network Octet Order)

I campi contrassegnati RESERVED (RSV) devono essere impostati su X'00'.

Se il metodo scelto include l'incapsulamento per scopi di autenticazione, integrità e/o riservatezza, le risposte sono incapsulate nell'incapsulamento dipendente dal metodo.

CONNECT​

Nella risposta a un CONNECT, BND.PORT contiene il numero di porta che il server ha assegnato per connettersi all'host di destinazione (Target Host), mentre BND.ADDR contiene l'indirizzo IP associato. Il BND.ADDR fornito è spesso diverso dall'indirizzo IP che il client utilizza per raggiungere il server SOCKS, poiché tali server sono spesso multi-homed (Multi-Homed). Si prevede che il server SOCKS utilizzi DST.ADDR e DST.PORT, nonché l'indirizzo sorgente e la porta lato client nella valutazione della richiesta CONNECT.

BIND​

La richiesta BIND (BIND Request) viene utilizzata nei protocolli che richiedono al client di accettare connessioni dal server. FTP è un esempio ben noto, che utilizza la connessione client-server primaria (Primary Client-to-Server Connection) per comandi e rapporti di stato, ma può utilizzare una connessione server-client (Server-to-Client Connection) per trasferire dati su richiesta (On Demand) (ad esempio LS, GET, PUT).

Si prevede che il lato client di un protocollo applicativo utilizzi la richiesta BIND solo per stabilire connessioni secondarie (Secondary Connection) dopo che una connessione primaria (Primary Connection) è stata stabilita utilizzando CONNECT. Si prevede che un server SOCKS utilizzi DST.ADDR e DST.PORT nella valutazione della richiesta BIND.

Durante un'operazione BIND vengono inviate due risposte dal server SOCKS al client. La prima viene inviata dopo che il server ha creato e vincolato un nuovo socket (Socket). Il campo BND.PORT contiene il numero di porta che il server SOCKS ha assegnato per ascoltare una connessione in entrata. Il campo BND.ADDR contiene l'indirizzo IP associato. Il client utilizzerà tipicamente queste informazioni per notificare (tramite la connessione primaria o di controllo) il server applicativo dell'indirizzo di rendezvous (Rendezvous Address). La seconda risposta si verifica solo dopo che la connessione in entrata anticipata ha avuto successo o è fallita.

Nella seconda risposta, i campi BND.PORT e BND.ADDR contengono l'indirizzo e il numero di porta dell'host che si connette.

UDP ASSOCIATE​

La richiesta UDP ASSOCIATE (UDP ASSOCIATE Request) viene utilizzata per stabilire un'associazione (Association) all'interno del processo di relay UDP (UDP Relay Process) per gestire i datagrammi UDP (UDP Datagram). I campi DST.ADDR e DST.PORT contengono l'indirizzo e la porta che il client prevede di utilizzare per inviare datagrammi UDP per l'associazione. Il server può utilizzare queste informazioni per limitare l'accesso all'associazione. Se il client non è in possesso delle informazioni al momento dell'UDP ASSOCIATE, il client deve utilizzare un numero di porta e un indirizzo di tutti zeri.

Un'associazione UDP termina quando la connessione TCP su cui è arrivata la richiesta UDP ASSOCIATE termina.

Nella risposta a una richiesta UDP ASSOCIATE, i campi BND.PORT e BND.ADDR indicano il numero di porta/indirizzo a cui il client deve inviare i messaggi di richiesta UDP da inoltrare.

Reply Processing (Elaborazione delle risposte)​

Quando una risposta (valore REP diverso da X'00') indica un fallimento, il server SOCKS deve terminare la connessione TCP poco dopo aver inviato la risposta. Questo deve avvenire non più di 10 secondi dopo aver rilevato la condizione che ha causato un fallimento.

Se il codice di risposta (valore REP di X'00') indica un successo e la richiesta era un BIND o un CONNECT, il client può ora iniziare a trasmettere dati. Se il metodo di autenticazione selezionato supporta l'incapsulamento per scopi di integrità, autenticazione e/o riservatezza, i dati sono incapsulati utilizzando l'incapsulamento dipendente dal metodo. Allo stesso modo, quando i dati arrivano al server SOCKS per il client, il server deve incapsulare i dati in modo appropriato per il metodo di autenticazione in uso.

Ultimo aggiornamento il