Yutaka Sato wrote:
> In message on 09/11/08(21:08:29)
> you Andre wrote:
> |> In message on 09/11/08(11:51:18) I wrote:
> |> | |We would also like to know whether it is possible to use the BIND
> |> | command to open a specific port on the SOCKS server
> |> | |not just for one client connection, but for multiple client connections.
> |> |
> |> |Is it possible with other implementations of a SOCKS server?
> |> |Since the tcp connection established by the BIND command on the SOCKS
> |> |protocol becomes a transparent connection with the remote peer after
> |> |the ACCEPT command, there is no chance to reuse it for another ACCEPT.
> |> If your intension is just to use a persistent port (as 80/HTTP)
> |> to accept client's connection via the SOCKS server, (not to repeat
> |> ACCEPT on the same SOCKS connection), you can use SRCIF with PORTS as this:
> |> PORTS="xx.xx.xx.xx:80"
> |> SRCIF="xx.xx.xx.xx:80:tcpbind"
> Sorry, it is not "PORTS" but "PORT" as the reference manual says :p
> |> If necessary, you can restrict this mapping of reserved port-number based
> |> on the destination host (to be indicated by the SOCKS client) and the
> |> IP-address of the SOCKS client's host, or by user name with AUTHORIZER.
> |This is my intention, but I would like to be able to do this at runtime,
> |so that I send a command to the server server that there is a service X
> |which wants
> |to accept connections through the server at a specific port. And this
> |should be a persistent port, possibly with timeout.
> I don't see the insufficiency by PORT and SRCIF for your requirement.
> If necessary, you can select a port to be bound dynamically based on the
> request from the SOCKS-client, using the DST.ADDR and/or DST.PORT field
> of the BIND command (which is intended to specify the control connection
> to a FTP server but will not be used in other protocols) to indicate the
> desired port to be bound, using a set of SRCIFs conditional on the
> destination host (SRCIF=host:port:proto:dsthost:srchost).
> You can omit PORT commands to reserve ports to be used. But reserving
> a port is desirable to keep the LISTEN queue alive persistently not to
> drop the connection requests for it when there is no SOCKS-client to
> bind/accept from the port.
I played around with the VSAP protocol as well as with the HTTP ACCEPT
and it works a long as I'm only dealing with one client. This is
probably due to the fact
that once a client connects to the opened port, this port becomes bound
by this client
so no other client can connect to this port.
I should probably explain my scenario a little more in detail.
Say I have three delegated proxies running somewhere and one, say HTTP
somewhere else. The HTTP server now wants to provide it's service, but
not directly from
his location, but from a location of one of the delegated proxies. The
HTTP server then connects
to one of the proxies and tells it that all requests made on a specific
port, should be forwarded/relayed
to it on httpserverIP:port.
If now a client, wants to connect to the HTTP server, it should do so by
connecting to the proxy:port
which the HTTP server assigned this responsibility. This is also due to
the fact that clients don't
know the real httpserverIP:port of the HTTP server.
So the proxy server needs to be capable of starting a second server
process, on a specific port,
on demand which only allows connecting transparently to httpserverIP:port.
This could for example be a HTTP/SOCKS proxy server only allowing
connect to httpserverIP:port.
Is such a thing already possible with the current implementation?