Бизнес-мудрость

Как сделать Double VPN — Подробная инструкция

В мире анонимайзеров нововведение, — Double VPN. Основной особенностью его является то, что сервер к которому мы подключаемся и сервер точкой выхода которого будет исходящий трафик, это два разных сервера, причем желательно расположенные в разных странах.

Особой сложности реализация такого механизма не представляет, хотя некоторые интересные моменты там есть. Типовая схема реализации маршрутизации трафика через OpenVPN сервер использует механизм NAT и собственно сам OpenVPN в режиме изменения основного шлюза. В этом случае весь трафик клиента перенаправляется на сервер OpenVPN, где уже направляется далее в сеть Internet с подменой адреса источника.

Графически простая схема с перенаправлением всего трафика клиента выглядит следующим образом:

Схема простой подмены адреса при помощи VPN

В простейшем виде конфигурация OpenVPN для такой схемы будет следующая:

port 1194
proto tcp
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt  
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key  # This file should be kept secret
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
duplicate-cn
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"

Переопределение основного шлюза определяется параметрами:

push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"

А маскардинг (NAT-трафика) для последующей отправки в интернет с подменой внутреннего адреса на внешний адрес Internet-сервера реализуется командой IP-tables:

iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE

Данные правила можно указать в конфигурационном файле /etc/rc.local для применения на этапе загрузки сервера.

Для реализации схемы двойного VPN, где адрес сервера к которому осуществляется подключение и адрес сервера с которого идет нешифрованный обмен — это два разных сервера выглядит несколько сложней.

Схема реализации DoubleVPN

Как видно из схемы, теперь сервера объединены еще одним шифрованным каналом с другой подсетью (10.0.0.1 и 10.0.0.1). Для объединения серверов можно использовать любые технологии туннелей, например L2TP (как построить L2TP-туннель можно прочитать в нашей заметке «Построение нешифрованных туннелей в локальной сети на базе L2TP»), но в нашем случае такая схема не сработала, видимо, из-за каких-то ограничений хостинг-провайдера и сервера были объединены при помощи OpenVPN TAP-сети.

Конфигурация первого сервера [86.110.117.250] /etc/openvpn/client-upstream.conf (это клиент который подключается к вышестоящему серверу):

client
dev tap-upstream
proto tcp
remote 86.110.117.247 1195
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
comp-lzo
verb 3

<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>

Ключи и сертификаты упакованы напрямую в конфигурационный файл.

Конфигурация сервера (второго [86.110.117.250]) /etc/openvpn/server-upstream.conf:

port 1195
proto tcp
dev tap-upstream
ca ca.crt
cert upstream-server.crt
key upstream-server.key
dh dh2048.pem
server 10.0.0.0 255.255.255.0
route 10.8.0.0 255.255.255.0
ifconfig-pool-persist upstream-ipp.txt
keepalive 10 120
duplicate-cn
comp-lzo
persist-key
persist-tun
verb 3

Конфигурация довольно типовая и ,единственное на что стоит обратить внимание, это дополнительный маршрут на подсеть 10.8.0.0/24 со второго сервера.

route 10.8.0.0 255.255.255.0

Без этого параметра будет непонятно как добраться до этой подсети и ее трафик уйдет в шлюз по умолчанию и работать, естественно, не будет.

Теперь самое интересное, а именно, — как перенаправить весь трафик пришедший с рабочей станции на второй сервер. Если просто поменять основной шлюз или попробовать создать два основных шлюза с разными метриками, или использовать перенаправление трафика средствами OpenVPN, то ничего из этого не выйдет и вы просто потеряете связь с сервером из-за проблем с маршрутизацией.

В этом случае необходимо использовать маршрутизацию в зависимости от источника, а не маршрутизацию по назначению. Не вдаваясь в подробности такая схема реализуется тремя командами:

ip route add default via 10.0.0.1 table 120
ip rule add from 10.8.0.0/24 table 120
iptables -t nat -A POSTROUTING -o tap-upstream -j MASQUERADE

Последняя команда служит для упрощения маршрутизации от клиента к вышестоящему серверу. Используя маскардинг нам не требуется сообщать клиенту маршрут до сети 10.0.0.0/24. Так же обратите внимание, что эти команды должны выполняться только после подключения к вышестоящему серверу и не добавляйте их в /etc/rc.local.

Создадим дополнительный скрипт /etc/openvpn/upstream-route.sh, содержащий эти команды:

#!/bin/sh

ip route add default via 10.0.0.1 table 120
ip rule add from 10.8.0.0/24 table 120
iptables -t nat -A POSTROUTING -o tap-upstream -j MASQUERADE

exit 0

Для запуска скрипта, при установлении связи с вышестоящим сервером, необходимо дополнить конфигурационный файл параметрами:

script-security 2
up upstream-route.sh

Используя такой подход с маршрутизацией по источнику можно строить самые разные комбинации вложенности.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>