VPS как анонимный прокси и не только…

Сегодня каждый пользователь Интернет может приобрести VPS и использовать удаленный сервер, например, для размещения собственного сайта или организации DNS сервера. В данном посте я расскажу о нестандартном использовании VPS: о том как создать личный анонимный прокси сервер и обеспечить резервный доступ к уже существующим сервисам.

Исходные данные:

• VPS в Европе (ОС FreeBSD8.3) с белым ip (yyy.yyy.yyy.yyy)
• Интернет-шлюз в России (ОС FreeBSD8.1) с белым ip (xxx.xxx.xxx.xxx)
• Локальная сеть за шлюзом с серверами (HTTP-SERVER, HTTPS-SERVER, PROXY-SERVER)

Доступ к Интернет ресурсу через анонимный прокси сервер

Client —> Интернет-шлюз (PF) —rdr—> Local Proxy Server (SQUID) —vpn—> VPS Proxy Server (SQUID) —> Internet

Файервол PF на Интернет-шлюзе

Для анонимного доступа к определенным ресурсам сформируем специальную таблицу PF ip адресов:

table <anonymous> persist file "/etc/pf/iplists/anonymsites.txt"

В нашей схеме клиент использует прозрачный прокси, поэтому в PF необходимо создать редирект:

$ext_ip="xxx.xxx.xxx.xxx" $int_if="внутренний интерфейс" rdr on $int_if proto tcp from $clients to <anonymous> port 80 -> $ext_ip port 3129 rdr on $int_if proto tcp from $clients to <anonymous> port 443 -> $ext_ip port 3129

Перенаправляем трафик, идущий от клиентов по портам 80, 443 на определенные ресурсы через локальный прокси сервер (порт 3129).

Локальный прокси сервер SQUID

В стандартную конфигурацию SQUID2.7, как прокси для локальной сети, необходимо внести следующие директивы:

http_port 3129 # анонимность в сети header_access From deny all header_access Server deny all header_access User-Agent deny all header_access WWW-Authenticate deny all header_access Link deny all header_access X-Forwarded-For deny all header_access Via deny all header_access Cache-Control deny all forwarded_for off # направим весь пришедший трафик на родительский прокси сервер на VPS через vpn-туннель cache_peer 10.10.10.250 parent 3128 0 no-query no-digest cache_peer_access 10.10.10.250 allow all never_direct allow all 

Туннель на основе OpenVPN

Создадим между Интернет-шлюзом и VPS vpn-туннель, установив openvpn сервер (10.10.10.1) на шлюзе, а клиент на VPS (10.10.10.250).

#Конфигурация OpenVPN сервера mode server tls-server port 2080 proto udp dev tun ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key dh /etc/openvpn/keys/dh1024.pem tls-auth /etc/openvpn/keys/ta.key 0 topology subnet ifconfig 10.10.10.1 255.255.255.0 keepalive 10 120 max-clients 10 comp-lzo cipher DES-EDE3-CBC user nobody group nogroup persist-key persist-tun verb 4 mute 20 client-to-client client-config-dir /etc/openvpn/ccd status /var/log/openvpn/openvpn-status.log log-append /var/log/openvpn/openvpn.log 

#Конфигурация OpenVPN клиента client dev tun proto udp remote xxx.xxx.xxx.xxx 2080 pull topology subnet user nobody group nobody persist-key persist-tun ca /usr/local/etc/openvpn/keys/ca.crt cert /usr/local/etc/openvpn/keys/vps.crt key /usr/local/etc/openvpn/keys/vps.key tls-client tls-auth /usr/local/etc/openvpn/keys/ta.key 1 cipher DES-EDE3-CBC comp-lzo verb 3 status /var/log/openvpn-status.log log /var/log/openvpn.log mute 20 

VPS прокси сервер SQUID

Cтандартная конфигурация SQUID2.7 с анонимным доступом.

http_port 3128 #анонимность в сети header_access From deny all header_access Server deny all header_access User-Agent deny all header_access WWW-Authenticate deny all header_access Link deny all header_access X-Forwarded-For deny all header_access Via deny all header_access Cache-Control deny all forwarded_for off 

Резервный доступ к серверам (HTTP, HTTPs) извне

Internet —> VPS (PF) —vpn+stunnel—> Интернет-шлюз (PF) —> локальный сервер (HTTP, HTTPs)

Файервол PF на VPS

Добавим редирект в файервол PF на VPS:

$ext_if="внешний интерфейс" rdr on $ext_if proto tcp from any to $ext_if port 80 -> 127.0.0.1 port 8180 rdr on $ext_if proto tcp from any to $ext_if port 443 -> 127.0.0.1 port 4443 

Будем перенаправлять трафик, предназначенный для веб-сервера за Интернет-шлюзом, на адрес локальной петли порты 8180 и 4443, на котором работает Stunnel.

Туннель Stunnel

Возможно было, конечно, обойтись и без Stunnel, просто добавив статический маршрут и проброс портов на PF до локального сервера, но решил поэкспериментировать. В данном случае Stunnel необходим для проксирования внешнего трафика на локальный веб-сервер (192.168.XXX.YYY). Конфигурация Stunnel на VPS и Интернет-шлюзе:

#stunnel.conf на VPS pid = /var/run/stunnel.pid debug = 4 output = /var/log/stunnel.log cert = /usr/local/etc/stunnel/stunnel.cert key = /usr/local/etc/stunnel/stunnel.key sslVersion = SSLv3 options = DONT_INSERT_EMPTY_FRAGMENTS ciphers = AES256-SHA socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 compression = rle [http] client = yes accept = 8180 connect = 10.10.10.1:8180 TIMEOUTclose = 0 [https] client = yes accept = 4443 connect = 10.10.10.1:4443 TIMEOUTclose = 0 

#stunnel.conf на Интернет-шлюзе pid = /var/run/stunnel.pid debug = 4 output = /var/log/stunnel.log cert = /usr/local/etc/stunnel/stunnel.cert key = /usr/local/etc/stunnel/stunnel.key sslVersion = SSLv3 options = DONT_INSERT_EMPTY_FRAGMENTS ciphers = AES256-SHA socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 compression = rle [http] accept = 8180 connect = 192.168.XXX.YYY:80 TIMEOUTclose = 0 [https] accept = 4443 connect = 192.168.XXX.YYY:443 TIMEOUTclose = 0 

Так, можно обеспечить резервный доступ к сервису через дополнительный белый ip. Например, домену example.com в DNS можно сопоставить основной внешний ip, а субдомену www.example.com (часто алиас для основного) — ip удаленного VPS.