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

    Общий рейтинг статьи: 4 (проголосовало 1 )
    Опубликовано:  [просмотров 4756]


    В мире анонимайзеров нововведение, - 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

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


    Обсуждение статьи
    Вопрос нашего пользователяВсе равно, тест на Ipper.ru палит использование VPN.
    Ответ на комментарийНа обоих узлах заблокируйте в iptables ICMP-входящие (ping) и палить не будет.
    Вопрос нашего пользователяИ куда эту инструкцию засовывать?
    Ответ на комментарийНа ваше усмотрение. Куда хотите туда и засовывайте.

    Ваш комментарий: