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.