Corporate proxy bypass

At a certain point in the development of any company, it comes to the realization that it is necessary to control the working hours of its employees. Unfortunately, many of them choose the wrong method - closing access to certain resources on a corporate proxy. It can be either icq or many other resources containing "wrong words". But very often icq, lj and other resources with “wrong words” are required at work, but the employer does not understand this. Do you still have many clients who contact you only through icq? Looking for answers to your questions, do you come across a solution in lj and twitter that are closed? What to do?


Of course, there are many webproxy that can open you a closed page, but what to do with ICQ? And is there any way to automate this process? Yes you can.

To solve the problem, we need an external server. Its role may be played by both a home computer under * nix and simple vds. Fortunately, many hosting companies now provide vds of small capacity for just a penny. Moreover, serious resources will not be required for our task.

How will it work?

As a rule, 80 (http) and 443 (ssl) ports remain open. We will take advantage of this. We will send an http tunnel to our vds (which does not fall under the black list) through port 80. All our requests, masquerading as ordinary http requests, will seamlessly go through the proxy and get to our vds. On vds the tunnel will look in the proxy. Thus, after all the settings, a kind of proxy will be launched on our working computer, on which there are no restrictions.

Customization

All further actions are relevant for freebsd. For other unix systems, differences should only be in assembly and installation. To configure, we will need:

1) VDS or a home unix computer that is constantly connected to the Internet.

2) httptunnel (take here: nocrew.org/software/httptunnel ). If you have windows, download the version for it as well. If the server is on freebsd, then httptunnel is in the ports / usr / ports / www / httptunnel.
3) some small proxy (3proxy, zipproxy (this will also save us traffic), polipo, etc).

I decided to take myself a polipo, in principle, only because in the ports he was the first to catch my eye. For more than a year of use in tunneling and application at work in business processes, he did not fail me. For those who will not install this under freebsd, you can get polipo here (http://www.pps.jussieu.fr/~jch/software/polipo/)

Let's start with the assembly and installation: Add to /etc/rc.conf:

$cd /usr/ports/www/httptunnel && make install && make clean
$cd /usr/ports/www/polipo && make install && make clean


polipo_enable="YES"

If the vds that we bought (or took an existing one), we decide to use only for tunneling, then just turn off apache (or any other web server), and thereby free up the 80 port we need. However, this rarely happens in life, there are already sites on the existing vds, and on the new one we would not mind placing new ones. For this case, there is a second option: we need to buy an additional ip (let it be: 2.2.2.2, and the main ip of our vds: 1.1.1.1), on it there will be a tunnel on port 80, and on the main - a web server. We connect an additional ip: in rc.conf: we tweak the apache config so that it listens to a strictly defined ip: we configure the polipo config: - The config is configured, now run it: $ / usr / local / etc / rc.d / polipo.sh start Raise the tunnel :

ifconfig em0 inet 2.2.2.2 netmask 255.255.255.255 alias



ifconfig_em0_alias0="inet 2.2.2.2 netmask 255.255.255.255"



$vi /usr/local/etc/apache/httpd.conf
Listen 1.1.1.1:80
Listen 1.1.1.1:443



$cd /usr/local/etc/polipo && cp ./config.simple ./config && vi ./config

proxyAddress = "2.2.2.2"
allowedClients = "127.0.0.1"
proxyPort = 3128

chunkHighMark = 819200
objectHighMark = 128





hts -F 2.2.2.2ogi128 2.2.2.2:80

Check if everything is in order and listen correctly:

$ netstat -na || grep tcp
tcp4 0 0 2.2.2.2.80 *. * LISTEN
tcp4 0 0 2.2. 2.2.3128 *. * LISTEN

Now on the local computer we start the client:

htc -P proxy.company.comhaps128 -F 1020 2.2.2.2:80 It

remains to fix the parameters of your browser, icq or other clients.
We prescribe to use the proxy with the parameters: server: localhost, port: 1020

Everything is ready, and if you configured everything correctly, icq will successfully connect to the server. In the future, I advise you to close the proxy with a firewall. Despite the fact that we told him to receive requests only from the local ip, they will constantly try to connect to him, which carries an additional load.