Aller au contenu principal

6. Replies (Réponses)

Les informations de requête SOCKS sont envoyées par le client dès qu'il a établi une connexion au serveur SOCKS et terminé les négociations d'authentification (Authentication Negotiation). Le serveur évalue la requête et renvoie une réponse formée comme suit :

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

Où :

  • VER version du protocole : X'05'
  • REP champ de réponse (Reply Field) :
    • X'00' succès (succeeded)
    • X'01' échec général du serveur SOCKS (general SOCKS server failure)
    • X'02' connexion non autorisée par l'ensemble de règles (connection not allowed by ruleset)
    • X'03' Réseau inaccessible (Network unreachable)
    • X'04' Hôte inaccessible (Host unreachable)
    • X'05' Connexion refusée (Connection refused)
    • X'06' TTL expiré (TTL expired)
    • X'07' Commande non prise en charge (Command not supported)
    • X'08' Type d'adresse non pris en charge (Address type not supported)
    • X'09' to X'FF' non assigné (unassigned)
  • RSV RÉSERVÉ (RESERVED)
  • ATYP type d'adresse de l'adresse suivante
    • IP V4 address : X'01'
    • DOMAINNAME : X'03'
    • IP V6 address : X'04'
  • BND.ADDR adresse liée au serveur (Server Bound Address)
  • BND.PORT port lié au serveur dans l'ordre des octets réseau (Server Bound Port in Network Octet Order)

Les champs marqués RESERVED (RSV) doivent être définis sur X'00'.

Si la méthode choisie inclut une encapsulation à des fins d'authentification, d'intégrité et/ou de confidentialité, les réponses sont encapsulées dans l'encapsulation dépendante de la méthode.

CONNECT​

Dans la réponse à un CONNECT, BND.PORT contient le numéro de port que le serveur a attribué pour se connecter à l'hôte cible (Target Host), tandis que BND.ADDR contient l'adresse IP associée. Le BND.ADDR fourni est souvent différent de l'adresse IP que le client utilise pour atteindre le serveur SOCKS, car de tels serveurs sont souvent multi-hébergés (Multi-Homed). On s'attend à ce que le serveur SOCKS utilise DST.ADDR et DST.PORT, ainsi que l'adresse source et le port côté client pour évaluer la requête CONNECT.

BIND​

La requête BIND (BIND Request) est utilisée dans les protocoles qui exigent que le client accepte des connexions du serveur. FTP est un exemple bien connu, qui utilise la connexion client-serveur primaire (Primary Client-to-Server Connection) pour les commandes et les rapports d'état, mais peut utiliser une connexion serveur-client (Server-to-Client Connection) pour transférer des données à la demande (On Demand) (par exemple LS, GET, PUT).

On s'attend à ce que le côté client d'un protocole d'application utilise la requête BIND uniquement pour établir des connexions secondaires (Secondary Connection) après qu'une connexion primaire (Primary Connection) ait été établie à l'aide de CONNECT. On s'attend à ce qu'un serveur SOCKS utilise DST.ADDR et DST.PORT pour évaluer la requête BIND.

Deux réponses sont envoyées du serveur SOCKS au client pendant une opération BIND. La première est envoyée après que le serveur ait créé et lié un nouveau socket (Socket). Le champ BND.PORT contient le numéro de port que le serveur SOCKS a attribué pour écouter une connexion entrante. Le champ BND.ADDR contient l'adresse IP associée. Le client utilisera généralement ces informations pour notifier (via la connexion primaire ou de contrôle) le serveur d'application de l'adresse de rendez-vous (Rendezvous Address). La deuxième réponse ne se produit qu'après que la connexion entrante anticipée ait réussi ou échoué.

Dans la deuxième réponse, les champs BND.PORT et BND.ADDR contiennent l'adresse et le numéro de port de l'hôte se connectant.

UDP ASSOCIATE​

La requête UDP ASSOCIATE (UDP ASSOCIATE Request) est utilisée pour établir une association (Association) au sein du processus de relais UDP (UDP Relay Process) pour gérer les datagrammes UDP (UDP Datagram). Les champs DST.ADDR et DST.PORT contiennent l'adresse et le port que le client s'attend à utiliser pour envoyer des datagrammes UDP pour l'association. Le serveur peut utiliser ces informations pour limiter l'accès à l'association. Si le client n'est pas en possession de ces informations au moment de l'UDP ASSOCIATE, le client doit utiliser un numéro de port et une adresse de tous zéros.

Une association UDP se termine lorsque la connexion TCP sur laquelle la requête UDP ASSOCIATE est arrivée se termine.

Dans la réponse à une requête UDP ASSOCIATE, les champs BND.PORT et BND.ADDR indiquent le numéro de port/adresse où le client doit envoyer les messages de requête UDP à relayer.

Reply Processing (Traitement des réponses)​

Lorsqu'une réponse (valeur REP autre que X'00') indique un échec, le serveur SOCKS doit terminer la connexion TCP peu de temps après l'envoi de la réponse. Cela doit être au plus 10 secondes après la détection de la condition ayant causé l'échec.

Si le code de réponse (valeur REP de X'00') indique un succès, et que la requête était soit un BIND soit un CONNECT, le client peut maintenant commencer à transmettre des données. Si la méthode d'authentification sélectionnée prend en charge l'encapsulation à des fins d'intégrité, d'authentification et/ou de confidentialité, les données sont encapsulées à l'aide de l'encapsulation dépendante de la méthode. De même, lorsque des données arrivent au serveur SOCKS pour le client, le serveur doit encapsuler les données de manière appropriée pour la méthode d'authentification en cours d'utilisation.

Dernière mise à jour le