Port forwarding - squid as a transperant proxy

A warm Hello to all!

FYI I’m running the latest version of OpenSuse, Ya! works like a top!

I’ve got squid setup as a local proxy ( local as in only one computer and not the LAN ) with which I can control internet access, bandwith etc… It works great when I point my browser to localhost:3128 but my goal is to make it transparent so that no matter whether proxy settings are entered or blank all traffic will be filtered by Squid. After some research supposedly there’s a way to forward ports 80 & 443 to 3128 using Iptables but I can’t seem to get it to work. Is there a special trick to port-forwarding with Iptables on a OpenSuse machine? Basically, How do I forward at least port 80 to 3128? Maybe there’s a better way to do it than to use Iptables?

Thanks in advance!

The most common solution I’ve seen is to run a lightweight proxy like dnsmasq on the client that does the port and address translation.
You then configure your browser’s proxy settings to point to localhost.

TSU

Please take the trouble to mention your exact version. Then we do not have to start calculating things like: this is posted on 2015-04-13, where can I find what the latest of the supported versions were at that date, … This thread will be here for years to come, and we want to be it easy interpretable for future users.

And of course typing the version is much shorter then typing this sort of indirect indication.

Sorry!

It’s Version 13.2

OK, could you explain what dnsmasq does? What’s it’s puporse? Will I still have to enter manual proxy settings?

Thanks for your time and patience!!!

Hmmmm…

All the scenarios I’ve used this were pre-setup, and “just worked.”
But, I can’t remember at the moment when/where I ran those.

In any case, this means a great opportunity to re-visit the whole concept… so…

Option 1
You can certainly write iptables rules, but unless you can find a suitable template this would require a bit of work, testing and would be effective system-wide which might not be desirable.

Option 2
Probably the most used solution which I generally described is to run a small, lightweight proxy server somewhere on your network… generally locally for individual users but could be as a network resource. Proxy servers will accept a connection, terminate and create a new connection on behalf of that User to the target. Proxy servers are particularly known for doing just about anything that can be imagined because it doesn’t pass the original session headers, it creates a whole new session and connection. When you set up a proxy server, you can point specified apps to this app for special handling, and doesn’t affect all your apps system-wide. A common interface used by practically all browsers and many Internet apps is SOCKS, when you make the setting in your web browser for instance it wouldn’t matter if your URL was http or https, it would be passed to your proxy which would then create the new connection according to your rules.

Option 3
Seems to me that maybe I overlooked the possibility you could just configure your apps to point to SQUID using SOCKS directly? Mabye just do that, and avoid setting up another proxy (possibly local) altogether.

So,
The next step would be to select a suitable proxy app.
Although IIRC I’ve used dnsmasq, maybe or maybe not it might be used. In any case, technology today now suggests using any of various javascript based app would be far better than anything traditional… Why?

  • Javacript based apps are single threaded which on the face of it would be a severe problem but isn’t Traditional apps built using other languages like Python, Perl, Java, Mono, etc require that resources be reserved and used for multiple simultaneous long running threads.
  • Javascript based apps may be single threaded, but they are extremely short-lived, so execute in a instant, ready to be used for the next task. There is no long running thread that could block other use or suck standing resources. This is why Node and nginx are extremely fast, scale enormously and involve almost no measurable overhead.

I’m interested in this enough I’ll be spending some time on this over the next few days, but my early investigation suggests several nodejs proxy servers, both installable using npm and published in github.

TSU