Squidery, sans ink
Mar. 20th, 2009 10:22 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
altivoToday, besides cataloging a stack of stuff, I configured the squid cache on the new server. Squid's a useful tool, but horribly complex. Fortunately I don't need many of its features.
Supposedly the old proxy server (still running, but not for much longer) that was configured and installed by an outside agency, had bandwidth controls and a squid cache. It was a black box to me for the last two years because it seemed to be working and the network architecture was such that I couldn't easily communicate with it or look inside. Even though I have the requisite passwords, they left me no documentation whatsoever on their setup, so I had to reverse engineer it by hunting down all the configuration files and such.
Turns out it was doing nothing except DHCP and pass-through. Squid was running but not actually getting any traffic because the IPtables weren't set up. Bandwidth control was supposed to be happening in squid, but since no traffic was going through it there was no bandwidth monitoring either.
This new setup is actually functional. Web traffic goes through the cache. Bandwidth is monitored independently using kernel enforced queue disciplines. There is no other way for that subnet to reach the outside except by going through this gateway. Just goes to show once again, if you want something done right, you have to do it yourself.
There may need to be some cache tuning, but we're functional now. To be absolutely sure, I'll probably install portsentry and tripwire on the machine even though it has no real exposure to the internet. (There's a hardware firewall between it and the real internet, so no inbound connection from outside can reach it.It's not set up to respond to anything but SSH from that direction in any case.) Probably the whole thing can go live on Monday.
Supposedly the old proxy server (still running, but not for much longer) that was configured and installed by an outside agency, had bandwidth controls and a squid cache. It was a black box to me for the last two years because it seemed to be working and the network architecture was such that I couldn't easily communicate with it or look inside. Even though I have the requisite passwords, they left me no documentation whatsoever on their setup, so I had to reverse engineer it by hunting down all the configuration files and such.
Turns out it was doing nothing except DHCP and pass-through. Squid was running but not actually getting any traffic because the IPtables weren't set up. Bandwidth control was supposed to be happening in squid, but since no traffic was going through it there was no bandwidth monitoring either.
This new setup is actually functional. Web traffic goes through the cache. Bandwidth is monitored independently using kernel enforced queue disciplines. There is no other way for that subnet to reach the outside except by going through this gateway. Just goes to show once again, if you want something done right, you have to do it yourself.
There may need to be some cache tuning, but we're functional now. To be absolutely sure, I'll probably install portsentry and tripwire on the machine even though it has no real exposure to the internet. (There's a hardware firewall between it and the real internet, so no inbound connection from outside can reach it.It's not set up to respond to anything but SSH from that direction in any case.) Probably the whole thing can go live on Monday.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2009-03-22 11:08 am (UTC)no subject
Date: 2009-03-22 02:31 pm (UTC)no subject
Date: 2009-03-22 09:53 pm (UTC)no subject
Date: 2009-03-24 01:33 am (UTC)