В мире анонимайзеров нововведение, — Double VPN. Основной особенностью его является то, что сервер к которому мы подключаемся и сервер точкой выхода которого будет исходящий трафик, это два разных сервера, причем желательно расположенные в разных странах.
Особой сложности реализация такого механизма не представляет, хотя некоторые интересные моменты там есть. Типовая схема реализации маршрутизации трафика через OpenVPN сервер использует механизм NAT и собственно сам OpenVPN в режиме изменения основного шлюза. В этом случае весь трафик клиента перенаправляется на сервер OpenVPN, где уже направляется далее в сеть Internet с подменой адреса источника.
Графически простая схема с перенаправлением всего трафика клиента выглядит следующим образом:
В простейшем виде конфигурация 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
Используя такой подход с маршрутизацией по источнику можно строить самые разные комбинации вложенности.