Conversation
adds support for "forwarding rules" whereby rules of the form -f "match_name:match_port,[user:pass@]upstream_name:upstream_port,remote_name:remote_port" cause microsocks to forward the *match* request to the *upstream* SOCKS5 server using the name *remote*. this is particularly useful for accessing webuis of devices attached to various remote private networks: one can run a private microsocks (or other SOCKS5 server) on the PC attached to the remote network, and point a local microsocks instance at that server, allowing specific names to be forwarded to the private network without affecting normal browser traffic.
correct. the beauty of it being that minimalistic is that lots of people can take the code, comprehend it, and augment it with their favorite feature, just like you guys did.
that's also true, though if such functionality is desired i'd like to point out that tinyproxy can do this since several years, but not just for socks5 proxies, it supports http/socks4a/socks5 upstreams using the upstream directive, along with lots of other features. the only functional difference is that the initial connection is done via http protocol instead of socks5. though i guess for some people what you and ohwgiles did might just be exactly what they need. |
|
Thanks for your reply. |
2 participants
This work is based on the forwarding rules idea proposed by @ohwgiles in #93.
On top of that initial implementation, this version fixes several functional
issues, improves stability, and adds support for global forwarding rules such as
0.0.0.0:0.Many thanks to @ohwgiles for the original idea.
It is acknowledged that this feature goes somewhat beyond the original design
goals of microsocks as a minimal SOCKS5 server. However, it can be useful in
practical scenarios where selectively forwarding specific destinations via an
upstream SOCKS proxy is required (e.g. accessing services in remote private
networks). This PR is therefore submitted as an optional enhancement for users
who may find it helpful.