Цитата сообщения Владимир_Шильников Интернет *на халяву*.


Перед тем как приступить к настройке, неплохо было бы ответить на вопрос: «А зачем это всё нужно?» Вариантов, когда такой доступ может оказаться полезным, масса. Например, у вас отключили Интернет за неуплату (как это обычно бывает в первый день месяца чуть позже полуночи), а вам срочно надо связаться с кем-то или перевести нужную сумму на счёт провайдера. До сих пор попадаются некоторые нехорошие компании, которые даже доступ к личному кабинету отключают при нулевом балансе, не давая тем самым хотя бы заблокировать аккаунт, и потихоньку списывют деньги за недоступную услугу. Или, к примеру, в вашей организации очень злобные админы (обязательно бородатые и в свитерах), которые блокируют доступ к мессенджерам, социальным сетям и прочим радостям простого офисного сотрудника. Бывает и так, что есть открытая сеть Wi-Fi, но, согласно политике безопасности, Интернет чужакам не положен. В общем, условие только одно — главное, чтобы вам был свободно доступен DNS-сервер!

Теория

С помощью техники IP-over-DNS можно организовать туннель для передачи произвольного трафика поверх протокола DNS. Исторически сложилось так, что размер пакета DNS не должен превышать 512 байт, чего как раз хватало для размещения информации о 13 корневых серверах (коих сейчас аж под 200 штук). Однако в нём, как правило, остаётся достаточно «свободного» места. Дальше начинается магия. У нас должен быть свой сервер в Сети, который на самом деле является фальшивым сервером имён, отвечающим за некую доменную зону. Мы посылаем DNS-запрос к нашему локальному (провайдерскому) DNS-серверу об этой самой зоне. Он, как и положено, интересуется у фальшивого сервера, что это за зона, а тот отвечает ему. Фактически мы уже «достучались» до нашего сервера в Интернете. Нюанс в том, что мы на самом деле всё это время не выходили за пределы локальной сети. Ну а дальше всё просто. Связь с сервером есть, обмениваться пакетами с ним можно. Остаётся только аккуратно резать весь трафик на небольшие кусочки, упаковывать их в свободное место в DNS-пакетах и отдавать их клиенту, который будет на своей стороне восстанавливать исходную последовательность. И, соответственно, таким же образом возвращать обратно, желательно ещё и с попутным сжатием трафика.

Вопрос о легальности такого доступа к Сети достаточно спорный. С одной стороны, мы вроде как не нарушаем спецификации и работаем с DNS как положено. «Легальные» запросы к DNS от фальшивых отличить невозможно. С другой стороны, все мы понимаем, что с моральной точки зрения это, скажем так, не совсем хорошо. Так что злоупотреблять данным методом точно не стоит. Подавляющее большинство провайдеров даже при отключенном доступе в Интернет оставляет свои DNS-сервера открытыми для пользователей, хотя некоторые и блокирует подозрительно «жирные» пакеты. В целом до сих пор нет достаточно универсального и действенного средства против IP-over-DNS. Хотя, конечно, паразитный трафик можно вычислить по резко возросшей частоте запросов к серверу имён или с помощью систем обнаружения вторжений.

Практика

Есть несколько реализаций методики IP-over-DNS: NSTX (наверное, самая старая), OzymanDNS, DNSCat, iodine и другие, как правило, написанные только для себя. На данный момент наилучшей реализацией считается проект iodine. В названии заключена своего рода игра слов. Во-первых, iodine содержит в себе аббревиатуру IP-over-DNS (IOD). Во-вторых, iodine, он же йод, имеет в периодической таблице порядковый номер 53, который совпадает с номером порта DNS по умолчанию. По факту это единственный проект, который более-менее регулярно обновляется и улучшается, а также портирован на большое количество платформ. К тому же и настройка его не требует особых усилий.

Впрочем, есть и более экзотические методики получения бесплатного доступа в Сеть. Например, IP-over-IRC или IP-over-XMPP, ведь многие провайдеры предоставляют бесплатный доступ к внутренним IRC- или Jabber-серверам, которые часто соединены с другими серверами в Сети. Есть и совсем безумная методика IP-over-ICMP (ICMPTX). Однако мы остановимся на IP-over-DNS и рассмотрим всё это дело на примере iodine.

Настройка сервера iodine

В качестве примера рассмотрим установку iodine на сервер с Ubuntu 10.04.1 в Amazon EC2, о настройке которого было рассказано в предыдущей статье. На всякий случай рекомендуется прочитать её ещё раз, чтобы не возникло лишних вопросов. Настройка для других дистрибутивов GNU/Linux производится аналогичным образом. Впрочем, если у вас есть такой сервер, то вряд ли потребуются дополнительные объяснения. На самом деле, лучше всего устанавливать iodine на сервер, который физически ближе к вам, хотя бы ради уменьшения времени отклика.

Для начала необходимо зарегистрировать домен, через который будут идти DNS-запросы. В принципе, можно выбрать любого регистратора, в том числе и бесплатного. Лишь бы была возможность менять NS-записи для создаваемых поддоменов. Для примера рассмотрим co.cc. Выбор этого сервиса не случаен. Во-первых, он не требует оплаты. Во-вторых, надо помнить, что чем короче будет наше доменное имя, тем, условно говоря, больше полезной информации уместится в DNS-пакете. На главной странице сервиса нам предлагают выбрать себе домен и, если он свободен, сразу же зарегистрироваться. Для единообразия в примере будет использоваться amazec2.co.cc, но вы можете выбрать любое подходящее имя, нажать на кнопку «Проверить доступность» и пройти остальную часть процедуры регистрации на сайте, с которой проблем быть не должно. Если доменное имя недоступно, то надо будет вернуться на главную страницу и попробовать другое.



После окончания регистрации надо залогиниться в сервисе, в My Domains выбрать домен и кликнуть по пункту Zone Record. Теперь заполним все нужные поля. В Host вводится имя поддомена (например, t.amazec2.co.cc), в Type выбираем NS, а в Value вводим DynDNS-имя нашего сервера в облаке Amazon EC2 (в нашем примере это был amazec2.dyndns-ip.com). Наконец, жмём кнопку «Выполните настройку». На делегирование домена понадобится некоторое время. На сайте сказано, что изменения вступают в силу в течение 48 часов, но на самом деле вряд ли придётся ждать больше часа. Впрочем, многое зависит от вашего провайдера. А пока, чтобы не скучать, займёмся настройкой сервера.



Для начала нам надо будет открыть 53-й порт на нашем сервере. Для этого заходим в консоль управления AWS, переходим в раздел Security Groups и в списке кликаем по default group. Переходим на вкладку Inbound. Выбираем в списке Create a new rule пункт DNS и жмём Add rule, а затем Apply Rule Changes. Должно получиться, как на скриншоте ниже.



Теперь немного упростим себе работу с SSH. Запускаем PuTTY, в поле Host Name вводим DynDNS-адрес сервера (в нашем примере это был amazec2.dyndns-ip.com). Затем переходим в меню слева в Connection → SSH → Auth и указываем в Private key file путь до нашего ключа в формате ppk. Чуть выше, в разделе Connection → Data есть поле Auto-login username, в которое надо ввести ubuntu (это наш логин). Наконец, в Window → Translation выбираем кодировку UTF-8 и возвращаемся в раздел Session. Здесь в поле Saved Sessions вводим любое имя (например, amazonvpn) и жмём справа Save. Теперь после запуска PuTTY достаточно будет дважды кликнуть по имени сохранённого соединения (amazonvpn) и консоль удалённого сервера откроется сама.









Откроем консоль и установим iodine следующей командой:

sudo apt-get install iodine

Теперь надо отредактировать файл конфигурации /etc/default/iodine

sudo nano /etc/default/iodine

и привести его к примерно такому виду:



Разберём вводимые параметры. 172.16.15.1 — это IP-адрес сервера внутри будущего DNS-туннеля. Вместо 172.16.15.1 можно выбрать любую другую локальную подсеть. Требование одно — адресация в туннеле не должна совпадать с адресацией вашего локального сетевого подключения. t.amazec2.co.cc — это поддомен, который мы регистрировали выше. Наконец, в IODINED_PASSWORD указывается пароль, который нужно будет ввести при последующем подключении. Сохраняем изменения нажав F2, затем Y и Enter.

Теперь надо узнать установленную версию iodine командой

iodine -v

и перезапустить демон iodine:

sudo /etc/init.d/iodined restart



Далее необходимо «подкрутить» маршрутизацию командами

sudo iptables -t filter -A FORWARD -i eth0 -o dns0 -m state --state RELATED,ESTABLISHED -j/
ACCEPT

sudo iptables -t filter -A FORWARD -i dns0 -o eth0 -j ACCEPT

и добавить их /etc/rc.local, не забыв сохранить файл после редактирования:

sudo nano /etc/rc.local

Должно получиться что-то вроде этого:



На этом настройка сервера iodine закончена, и из консоли можно выйти командой exit. Напоследок пара комментариев для тех, кто устанавливает iodine на собственный сервер. Во-первых, не забудьте про net.ipv4.ip_forward=1. Во-вторых, если у вас на 53-м порту уже работает BIND, то на страничке Tips and tricks проекта есть полезные указания на этот счёт. Там же, кстати, есть и ссылка на скрипт для быстрой настройки маршрутов в Mac OS X, GNU/Linux и FreeBSD при использовании под этими ОС клиента iodine.

Настройка клиента iodine

Клиентской частью, как и в прошлый раз, будет выступать 32-битная Windows 7. Начать надо с установки виртуального TAP-адаптера из пакета OpenVPN. Можно скачать только драйвер (запустить addtap.bat) или подобрать релиз посвежее отсюда и при установке выбрать только TAP Virtual Ethernet Adapter.



При установке драйвера система попросит разрешения на выполнение этого действия. Отказываться не стоит.



Заходим в «Панель управления», выбираем «Центр управления сетями и общим доступом» и слева жмём на пункт «Изменение параметров адаптера». Здесь нам нужно будет поменять имя свежесозданного сетевого адаптера на dns.



Со страницы проекта iodine скачиваем архив с версией программы под Windows. Учтите, что номер версии у сервера (его мы узнали чуть выше) и клиента должны совпадать. В нашем случае сервер был версии 0.5.1, а значит, скачивать нужно архив iodine-0.5.1-win32.zip. После скачивания распакуйте архив в какую-нибудь папку.

Для настройки маршрутов надо узнать IP-адреса местного DNS-сервера и шлюза по умолчанию. В командной строке Windows (Win+R, cmd, Enter) вводим команду

ipconfig /all

и смотрим свойства локального сетевого подключения. В нашем примере будет использован DNS по адресу 195.94.59.1 и шлюз с IP 172.30.4.1.



Поднимем iodine-туннель командой

c:\путь\до\iodine.exe -f 195.94.59.1 t.amazec2.co.cc

Вместо 195.94.59.1 подставляем свой DNS-сервер, а вместо t.amazec2.co.cc — свой поддомен. Нас попросят ввести пароль, который мы указывали выше в переменной IODINED_PASSWORD. Если вы всё правильно сделали, то туннель через несколько секунд поднимется. Большим подспорьем является то, что iodine автоматически определяет размер MTU. Для опускания туннеля достаточно будет закрыть окно с запущенным клиентом iodine.



Можно проверить доступность сервера, открыв ещё одно окно командной строки и введя

ping 172.16.15.1

где 172.16.15.1 — туннельный адрес сервера (см. выше). Если всё в порядке, то сервер откликнется.


Как и в прошлый раз, можно запустить SOCKS-сервер через PuTTY, который будет доступен по адресу 127.0.0.1 на порту 9999:

c:\путь\до\putty.exe -l ubuntu -D 9999 172.16.15.1 -i c:\путь\до\файла.ppk

Но лучше этого, конечно, не делать, а закрыть PuTTY и настроить маршрутизацию в Windows. Должно получиться так, чтобы запросы к локальному DNS-серверу шли через шлюз по умолчанию, а весь остальной трафик «заворачивался» к нашему серверу в облаке Amazon EC2. Делается это несложно. Открываем ещё одну командную строку Windows и вводим следующие команды:

route delete 0.0.0.0

route add 195.94.59.1 mask 255.255.255.255 172.30.4.1

route add 0.0.0.0 mask 0.0.0.0 172.16.15.1

Опять-таки, вместо 195.94.59.1 подставляем адрес локального DNS, вместо 172.30.4.1 — адрес шлюза, вместо 172.16.15.1 — адрес iodine-сервера в туннеле. Всё, теперь можно пользоваться интернет-программами в обычном режиме. Ну почти в обычном — не забываем о маленькой скорости.



Чтобы прекратить всё это безобразие, надо закрыть окно с запущенным клиентом iodine, а в командной строке ввести две команды:

ipconfig /release

ipconfig /renew

Заключение

Фактическая скорость полученного соединения будет крайне невелика — скорее всего, от 1-2 до 10-20 кбит/с. Хотя у автора проекта в тестовой среде, близкой к идеальной, получались и более солидные цифры. Для всяческих чатов этого вполне должно хватить. А вот для просмотра веб-страничек лучше воспользоваться браузером Opera. Во-первых, в нём можно быстро отключить загрузку изображений. Во-вторых, у него есть режим Turbo, когда трафик предварительно сжимается на сторонних серверах. Для других браузеров есть похожие плагины, в том числе и использующие сервера Opera. Впрочем, существует и множество других аналогичных сервисов. Также рекомендуется «прибить» программы, которые могут активно использовать сеть в фоновом режиме. Например, торрент-клиенты или автообновления для ПО. Ну и не стоит забывать, что выход из нашего туннеля находится в США. Напоследок ещё раз напомним, что злоупотреблять таким методом доступа в Сеть не надо — использовать его стоит только в крайнем случае. Не ровен час, провайдер обидится и отлучит вас от Сети.
http://digest.subscribe.ru/inet/inet/n543019424.html