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

HELP-ME-24.COM (Freelance Team), Черноусов Антон

В мире анонимайзеров нововведение, - 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, где адрес сервера к которому осуществляется подключение и адрес сервера с которого идет нешифрованный обмен эта два разных сервера выглядит несколько сложней.

Как видно из схемы теперь сервера объединены еще одним шифрованным каналом с другой подсетью (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

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

Оставьте комментарий

Вы должны быть вошедший в чтобы отправить комментарий