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
Стандартні конфігурація 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.
 
  
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.