f.f.o. :: /add

Александр Фенстер

add@fenster.name fenster.name

Все записи

[798] 1 октября 2012; 0:45

Нечасто бывает такое, что нагугленная программа вот так прямо сразу раз — и работает. Особенно когда эта программа делает что-то вроде «VPN для бедных»: каждый, кто когда-нибудь настраивал openvpn или, не дай Бог, pptp, понимает, что это не такая простая задача. А тут внезапно работающее «из коробки» решение, на запуск которого я потратил примерно минуту: прочитал самое начало мануала и скопировал команду запуска из него в консольку. Когда видишь такой класс, трудно удержаться и не написать про это пост — вот я и не удержался.

А началось всё с того, что пару недель назад у нас начались проблемы с просмотром мультиков на YouTube. У нас Yota, и я ей более чем доволен — точнее, был доволен до тех пор, пока внезапно не началась фигня с загрузкой видео: независимо от выбранного качества (хоть 240, хоть 360, хоть 480) через несколько секунд после запуска воспроизведения загрузка останавливается, и возобновить её получается только полной перезагрузкой страницы браузера. Это случалось не постоянно, но вечером и в выходные — очень часто. После недели мучений стало понятно, что так жить нельзя.

Немного смущал тот факт, что замедления скорости интернета заметно не было: странички открывались так же шустро, как и раньше. Но YouTube смотреть было сложно. Не особо веря в успех, я поднял squid на своём хостинге, и мы с удивлением обнаружили, что через прокси видео проигрывается столь же хорошо, как и раньше — если не лучше. Вывод очевиден: враги шейпят трафик до ютуба.

Обращение в техподдержку через формочку на сайте Yota ничего не дало: ответа я так и не дождался. Да и не факт, что виновата именно Yota, а не их апстрим-провайдер, кем бы он ни был. Я далёк от мысли связывать проблемы с воспроизведением видео с циркулирующими в последнее время новостями о возможной блокировке YouTube в России: думаю, здесь имеет место простая попытка чуть-чуть сэкономить, а то, мол, ишь чего захотели, видео смотрят на безлимитных тарифах. В общем, причины не так важны — хочется понять, как бороться с последствиями.

HTTP-прокси — это как-то совсем глупо и неудобно. Нормальные люди для туннелирования трафика (в общем, всего, а не только http/https) используют, как известно, VPN. Проблема состоит в том, что мой любимый и единственный хостер Rusonyx, у которого я держу VPS (контейнер на Virtuozzo) где-то примерно с 2006 года, хорош всем, кроме ничем не объяснимого нежелания разрешать моему контейнеру использовать tun-девайс. Настолько ничем не объяснимого, что однажды на заданный в очередной раз вопрос на эту тему я получил вот такой краткий, но ёмкий ответ от саппорта:

From: "Rusonyx Support Team" <support@rusonyx.ru>
Date: Tue, 07 Oct 2008 16:51:44 +0400

Здравствуйте!

Вы писали:
> Пару лет назад я интересовался, можно ли использовать на VPS
> VPN-подключения через /dev/net/tun. Ответ был отрицательным.
>
> Изменилось ли что-либо в этой области? Попробовал поднять openvpn на
> своей VPS fenster.name -- Permission denied при обращении к /dev/net/tun.
> Насколько мне известно (и разработчики Virtuozzo это подтверждали
> неоднократно), разрешение использовать этот девайс совершенно безопасно.
> Можно ли это сделать?

Нет.

В то время иметь адекватный VPS-хостинг в России (чтобы сайт быстро грузился из НГУ) мне было важнее, чем иметь возможность запускать на этом хостинге openvpn, а сейчас уже не очень хочется переезжать к другому хостеру (хотя иногда, конечно, бывает желание — но про это, наверное, в другой раз).

Так или иначе, но у меня есть хостинг с рутовым доступом, но нет возможности держать там VPN-сервер.

И тут абсолютно внезапно после трёх минут гугления я наткнулся на sshuttle. Автор софтины сделал совершенно правильное предположение: во многих случаях VPN нужен не для двунаправленного соединения (чтобы с сервера можно было зайти на клиента), а только для туннелирования клиентского трафика через сервер. В итоге sshuttle не делает VPN в прямом смысле этого слова: она просто слушает локальный порт на клиенте и добавляет в iptables в табличку nat правило, заворачивающее на этот порт всех, кто пытается вылезти с клиента наружу. Далее данные пересылаются через ssh на сервер, где разворачиваются и отправляются по назначению. В общем, звучит всё логично, хотя какой-то небольшой кусочек непонятной мне магии здесь несомненно присутствует.

Как я уже писал в самом начале, штуковина just works, и это привело меня в полный восторг. Оно, конечно, понятно, что возможность для клиента выхода наружу по SSH сразу же делает все прочие ограничения бессмысленными, но я никогда раньше не видел настолько изящного способа туннелирования трафика — даже никаких ssh -L придумывать не надо. Так что, господа, имейте в виду: sshuttle — совершенно незаменимая штука в тех редких ситуациях, когда твой домашний провайдер считает допустимым сэкономить, пошейпив трафик до ютуба, а твой хостер считает допустимым не позволять тебе запускать VPN на арендованном виртуальном сервере. Работает на линуксе, а также, вроде как, на BSD и макоси. Такие дела.