TOR роутер на базе Raspberry с поддержкой VPN
InfoBiz
Постановка задачи: получить одноплатный компьютер, который можно подключить к своему ноутбуку/ПК/мобильному устройству и который будет заворачивать трафик сначала в VPN, затем в Tor, обфусцировать с помощью obfs-proxy и отправлять на удаленный VPN-сервер.
Исходные данные:
1) Одноплатный компьютер. В моем случае это Raspberry Pi модель B+;
2) ОС Raspbian. Для данной статьи использовалась Raspbian Jessie, билд от 18-03-2016;
3) Карта памяти (Micro SD);
4) Картридер;
5) Беспроводной адаптер или переходник ethernet to usb;
6) Удаленный OpenVPN сервер.
Схемы подключения:
1) eth-eth
2) wlan-eth
3) wlan-wlan
4) eth-wlan
Обозначения:
1. SBC — одноплатный компьютер;
2. CR — устройство, через которое осуществляется доступ в Интернет. Устройство не обязательно может быть подключено напрямую в порт SBC;
3. PC — какой-либо компьютер (или мобильное устройство) подключаемое к SBC;
4. VPN-server — целевой VPN сервер;
5. Входной интерфейс — физический интерфейс, куда поступает клиентский трафик;
6. Выходной интерфейс — физический интерфейс, с которого трафик уходит в Интернет.
Допущения:
В статье рассматривается случай, когда параметры для линка в интернет приходят по DHCP или задаются статически. Для случаев с получением параметров для линка по L2TP, PPPoE или иных ситуаций настройка будет отличаться. Также будем считать, что для удобной работы VPN-сервер выступает как DNS-relay.
Установка системы и подключение
На официальном сайте Rasbian присутствуют очень подробные инструкции для записи образа для Linux, Mac OS и Windows, поэтому я не буду описывать процесс записи образа ОС на карту памяти, чтобы не загромождать статью. Лучше брать карту от 16 Гб, чтобы избежать в будущем проблем с нехваткой памяти.
С подключением к плате после записи образа и включения может быть несколько вариантов:
1) Если у вас есть специальный экран/монитор/телевизор c поддержкой hdmi, то достаточно его подключить по hdmi;
2) Если экрана нет, но параметры на физический интерфейс приходят по DHCP, то можно просканировать сеть nmap-ом с другого компьютера и подключиться по ssh. Пользователь pi, пароль raspberry;
3) Если нет DHCP, то можно отредактировать файл /etc/network/interfaces и прописать туда адреса вручную.
Форвардинг трафика
Для того, чтобы трафик пересылался с одного интерфейса на другой, необходимо, чтобы был включен соответствующий параметр ядра Linux. Это можно сделать с помощью команды:
sysctl -w net.ipv4.ip_forward=1
или
<span class="hljs-built_in">echo</span> 1 >/proc/sys/net/ipv4/ip_forward
Для проверки можно использовать команду:
cat /proc/sys/net/ipv4/ip_forward
Она должна вернуть «1».
iptables
Для того, чтобы упростить маршрутизацию трафика, включим маскардинг для туннельного интерфейса с помощью iptables:
iptables -t nat -A POSTROUTING<span class="hljs-_">-s</span>10.5.5.0/24 -o tun0 -j MASQUERADE
Вместо этого можно было бы прописать статические маршруты и статический адрес для клиента. Или использовать ccd.
Установка пакетов
Обновить репозитории и получить обновления:
sudo apt-get update
sudo apt-get upgrade
Установка из репозиториев:
sudo apt-get install python2.7python-pip python-dev build-essential tor openvpn obfs-proxy
Если вы хотите схему с точкой доступа, то помимо этого установим hostapd и DHCP-cервер:
sudo apt-get install hostapd isc-dhcp-server
Вместо isc-dhcp-server вполне может быть использован любой другой. В репозиториях часто содержаться не самые последние версии, поэтому можно собрать пакеты из исходников, но если вам нужно получить быстрое решение, то подойдет и установка из репозитория.
Настройка сетевого подключения
Схема eth-eth
Данный вариант является самым простым. На физическом интерфейсе Raspberry Pi, к которому подключается ПК, достаточно настроить статический адрес. На ПК также задать параметры вручную. Также можно настроить isc-dhcp-server, чтобы он выдавал параметры. На клиентской машине на Linux для первоначальной настройки достаточно выполнить команды:
ip a add 10.5.5.2/24 dev<интерфейс>
ip route add default gw 10.5.5.1
А в файл /etc/resolv.conf добавить запись:
nameserver 10.8.0.1
Схема wlan-eth
В данной схеме входным интерфейсом будет беспроводной интерфейс, работающий в режиме точки доступа. Вместо режима полноценной точки доступа можно настроить режим Ad-hoc.
Для организации wi-fi точки доступа с DHCP я использовал связку hostapd и isc-dhcp-server, но не обязательно использовать именно эту связку.
Привожу пример настроек:
/etc/hostapd/hostapd.conf1
interface=wlan0 <span class="hljs-comment">#Интерфейс </span>
driver=rtl871xdrv <span class="hljs-comment">#Используемый драйвер</span>
ssid=AP <span class="hljs-comment">#Название точки доступа</span>
hw_mode=g <span class="hljs-comment">#Стандарт работы точки доступа</span>
channel=6 <span class="hljs-comment">#Частотный диапазон</span>
macaddr_acl=0 <span class="hljs-comment">#Не использовать списки доступа</span>
auth_algs=1 <span class="hljs-comment">#Использовать WPA</span>
wpa=2 <span class="hljs-comment">#Версия протокола</span>
wpa_passphrase=raspberry <span class="hljs-comment">#Пароль для подключения</span>
wpa_key_mgmt=WPA-PSK <span class="hljs-comment">#Метод аутентификации</span>
wpa_pairwise=TKIP <span class="hljs-comment">#Алгоритмы работы с ключами и шифрованием</span>
rsn_pairwise=CCMP
/etc/dhcp/dhcpd.conf1
<span class="hljs-comment">#Задание подсети для которой будет работать данный DHCP сервер</span>
subnet 10.5.5.0 netmask255.255.255.0 {
range 10.5.5.2 10.5.5.4; <span class="hljs-comment">#Диапазон адресов</span>
option broadcast-address10.5.5.255; <span class="hljs-comment">#Широковещательный адрес</span>
option routers 10.5.5.1; <span class="hljs-comment">#Шлюз по умолчанию</span>
default-lease-time 600; <span class="hljs-comment">#Стандартное удержания адреса</span>
max-lease-time 7200; <span class="hljs-comment">#Максимальное время удерживания адреса</span>
option domain-name <span class="hljs-string">"local"</span>;<span class="hljs-comment">#Доменное имя </span>
option domain-name-servers10.8.0.1;} <span class="hljs-comment">#Список DNS-серверов.</span>
Сразу стоит оговориться, что у некоторых могут возникнуть проблемы с драйверами и работой беспроводной карточки в режиме точки доступа. Лучше поинтересоваться такими вещами заранее.
Схема wlan-wlan
Часть с настройкой входного интерфейса ничем не отличается от предыдущей схемы. Выходной интерфейс необходимо подключить к точке доступа. Пример подключения с использованием утилиты nmcli:
nmcli d wifi connect <SSIDточки> password <пароль>iface <интерфейс>
Схема eth-wlan
Настройка входного интерфейса происходит как в схеме eth-eth, выходного — как в wlan-wlan.
Tor + obfsproxy
Для маскировки Tor трафика будем использовать obfsproxy.
Привожу пример настройки Tor:
/etc/tor/torrc1
SocksPort 9050
RunAsDaemon 1
VirtualAddrNetwork 172.16.0.0/12
DNSPort 53
DNSListenAddress 127.0.0.1
AutomapHostsOnResolve 1
BridgeRelay 1
Exitpolicy reject *:*
ServerTransportPlugin obfs3 <span class="hljs-built_in">exec</span>/usr/bin/obfsproxy managed
obfs3 <адрес1:порт1><ключ1>
obfs3 <адрес2:порт2><ключ2>
obfs3 <адрес3:порт3><ключ3>
Данные для подключения к серверам obfsproxy можно взять здесь.
OpenVPN
Для организации VPN будем использовать OpenVPN через TCP и в режиме L3 (tap-интерфейс). Используется TCP, поскольку Tor работает только TCP-трафиком. В сам же VPN-туннель можно пускать любой трафик. Для того, чтобы направить VPN трафик в Tor, будем «проксировать» весь VPN-трафик через Tor. OpenVPN поддерживает такую возможность.
Привожу пример настройки клиентской части OpenVPN с подробными комментариями:
/etc/openvpn/client.conf1
сlient <span class="hljs-comment">#Имя клиента</span>
dev tun <span class="hljs-comment">#Использовать L3-интерфейс</span>
proto tcp <span class="hljs-comment">#Задать TCP транспортным протоколом</span>
socks-proxy 127.0.0.1 9050 <span class="hljs-comment">#Использовать Tor как Socks-proxy. </span>
socks-proxy-retry <span class="hljs-comment">#Пытаться подключаться многократно</span>
<span class="hljs-comment"># Внешний IP, на или за которым находится сервер OpenVPN и порт (на сервере или на сетевом устройстве, на котором настроен проброс портов до сервера)</span>
remote 1.1.1.1 443 <span class="hljs-comment">#Порт специально выбран таким образом, чтобы он совпадал с портом, используемым протоколом https. </span>
resolv-retry infinite <span class="hljs-comment">#Подключаться до тех пор, пока подключение не будет осуществлено.</span>
ca /etc/openvpn/keys/ca.crt <span class="hljs-comment">#Сертификат сервера</span>
cert /etc/openvpn/keys/client.crt<span class="hljs-comment">#Сертификат клиента</span>
key /etc/openvpn/keys/client.key<span class="hljs-comment">#Приватный ключ клиента</span>
tls-client <span class="hljs-comment">#Использовать протокол TLS</span>
tls-auth /etc/openvpn/keys/ta.key 1<span class="hljs-comment">#Ключ для аутентификации в TLS</span>
auth SHA1 <span class="hljs-comment">#Задать SHA1 как алгоритм хеширования</span>
cipher AES-128-CBC <span class="hljs-comment">#Задать основным алгоритмом шифрования AES с длиной ключа в 128 бит в режиме сцепления блоков.</span>
По настройке сервера есть достаточно много инструкцией в интернете. Ключевым в настройке является совпадение параметров и наличие в конфиге сервера строчки «push «redirect-gateway def»». Она необходима, чтобы на клиенте установился маршрут по-умолчанию для проходящего трафика, который указывает на VPN сервер.
Тестирование
Для теста правильности работы пустим ping от подключенного ПК до tun-интерфейса VPN-сервера, будем снимать трафик с помощью tcpdump и анализировать в Wireshark для наглядности.
1) ICMP-запрос приходит на входной интерфейс Raspberry Pi.
Стоит обратить внимание на идентификаторы BE, LE и временную метку. Далее они нужны будут для того, чтобы опознать ICMP-запрос на стороне сервера.
2) ICMP-пакет прошёл процедуру обработки в OpenVPN и направился на порт 9050, который «слушается» Tor. Снимок трафика происходит на loopback интерфейсе Raspberry Pi.
3) Пакет выходит из Raspberry Pi и направляется на один из узлов сети Tor с серверной частью obfsproxy:
4) И снимок трафика уже на туннельном интерфейсе VPN-сервера. Тут же можно заметить, что сервер послал ответ.
Идентификаторы BE, LE и временная метка совпадают с теми, которые были в отправленном пакете.
5) На этом скриншоте представлен пакет, выходящий с VPN-сервера, в котором содержиться ICMP-reply.
Также я произвел тестирование пропускной способности этого решения с помощью iperf для TCP и UDP трафика до сервера. Тестирование проводилось с использованием Raspberry Pi model B+ и ОС Raspbian в домашней сети, так что цифры для других одноплатных компьютеров с другими ОС или другой сетевой средой могут отличаться.
Результаты:
— связка Tor + VPN+ obfsproxy
— только VPN
— чистый канал
Заключение
Потенциальные подводные камни:
1) Синхронизация времени. Поскольку tor выполняет криптооперации с проверкой временных меток, то время должно быть синхронизировано. К сожалению, время нужно будет синхронизировать каждый раз после выключения платы.
2) Размер mtu. DF-бит в отправляемых пакетах может привести к тому, что трафик будет «резаться», если где-то по пути запрещена фрагментация пакетов, а значение mtu меньше вашего.
3) Использование VPN throught Tor и obfsproxy не панацея от всего.