yarrick/iodineТуннелирование данных IPv4 через DNS-серверы для обхода ограничений брандмауэра и обеспечения скрытого сетевого доступа при тестировании на проникновение.
Это программное обеспечение позволяет туннелировать данные IPv4 через DNS-сервер. Это может пригодиться в различных ситуациях, когда доступ в интернет ограничен межсетевым экраном, но DNS-запросы разрешены.
У iodine нет configure-скрипта. Есть две опциональные возможности для Linux (поддержка SELinux и systemd), которые включаются автоматически, если соответствующие заголовочные файлы найдены в /usr/include.
(См. скрипт в ./src/osflags)
Выполните make для компиляции серверных и клиентских бинарных файлов.
Выполните make install для копирования бинарных файлов и man-страницы в целевой каталог.
Выполните make test для компиляции и запуска модульных тестов. (Требуется библиотека check)
Попробуйте в своей локальной сети! Выполните следующие простые шаги:
./iodined -f 10.0.0.1 test.com.
Если вы уже используете сеть 10.0.0.0, возьмите другую внутреннюю сеть, например 172.16.0.0../iodine -f -r 192.168.0.1 test.com.
Замените 192.168.0.1 на IP-адрес вашего сервера.10.0.0.2, а сервер — 10.0.0.1.Примечание: сервер и клиент обязаны использовать один и тот же протокол. В большинстве случаев это означает запуск одной и той же версии iodine. К сожалению, реализация обратной и прямой совместимости протоколов обычно нецелесообразна.
Чтобы использовать этот туннель, вам нужен контроль над реальным доменом (например, mydomain.com) и сервер с публичным IP-адресом для запуска iodined. Если на этом сервере уже работает DNS-программа, измените её порт прослушивания и затем используйте опцию -b программы iodined, чтобы разрешить iodined пересылать DNS-запросы. (Обратите внимание, что эта процедура не рекомендуется для производственных сред, поскольку пересылка DNS в iodined не является полностью прозрачной; например, передача зон работать не будет.) В качестве альтернативы можно перенаправить поддомен с вашего DNS-сервера на iodined, который в этом случае должен работать на другом порту (-p).
Затем делегируйте поддомен (например, t1.mydomain.com) серверу iodined. Если вы используете BIND для своего домена, добавьте в файл зоны две строки:
t1 IN NS t1ns.mydomain.com. ; note the dot!
t1ns IN A 10.15.213.99
Строки NS достаточно, чтобы направлять запросы для поддомена t1 на сервер t1ns. Мы используем короткое имя для поддомена, чтобы оставить как можно больше места для передачи данных. В конце строки NS указывается имя вашего сервера iodined. Это может быть любое имя, указывающее куда угодно, но в данном случае его удобно хранить в том же файле зоны. Это должно быть имя (не IP-адрес), и для самого этого имени должна существовать запись A (не CNAME).
Если ваш сервер iodined имеет динамический IP, воспользуйтесь провайдером динамического DNS. Просто укажите его в строке NS и опустите строку A:
t1 IN NS myname.mydyndnsprovider.com. ; note the dot!
Затем перезагрузите или перезапустите вашу программу-неймсервер. Теперь все DNS-запросы для доменов, оканчивающихся на t1.mydomain.com, будут отправляться вашему серверу iodined.
Наконец, запустите iodined на вашем сервере. Первый аргумент — IP-адрес внутри туннеля, который может быть из любого диапазона, который вы пока не используете (например, 192.168.99.1), а второй аргумент — назначенный домен (в данном случае t1.mydomain.com). Опция -f оставляет iodined запущенным на переднем плане, что удобно при тестировании. iodined откроет виртуальный интерфейс («tun-устройство»), а также начнёт прослушивать DNS-запросы на UDP-порту 53. Введите пароль либо в командной строке (-P pass), либо после запуска сервера. Теперь всё готово для клиента.
Если есть вероятность, что туннель iodine будет использоваться из непредвиденных окружений, запускайте iodined с опцией -c.
Итоговая командная строка в этом примере:
./iodined -f -c -P secretpassword 192.168.99.1 t1.mydomain.com
Вся настройка завершена, просто запустите iodine. Он принимает один или два аргумента: первый — локальный ретранслирующий DNS-сервер (необязательно), второй — используемый вами домен (t1.mydomain.com). Если первый аргумент не указан, будет использована текущая DNS-настройка системы.
Если DNS-запросы разрешены к любому компьютеру, вы можете напрямую указать адрес сервера iodined первым аргументом (в примере: t1ns.mydomain.com или 10.15.213.99). В этом случае может также оказаться, что любой трафик разрешён к DNS-порту (53 UDP) любого компьютера. Iodine обнаружит это и переключится на «сырой» UDP-туннель, если это возможно. Чтобы в любом случае принудительно использовать DNS-туннелирование, применяйте опцию -r (особенно полезно при тестировании в собственной сети).
Туннельный интерфейс клиента получит IP-адрес, близкий к адресу сервера (в данном случае 192.168.99.2 или .3 и т.д.), и подходящий MTU. Введите тот же пароль, что и на сервере, либо в качестве опции командной строки, либо после запуска клиента. Опция -f оставляет клиент iodine запущенным на переднем плане.
Итоговая командная строка в этом примере: добавление -r принудительно включает DNS-туннелирование, даже если «сырой» UDP-туннель был бы возможен:
./iodine -f -P secretpassword t1.mydomain.com
С любой стороны теперь можно пинговать IP-адрес на другом конце туннеля. В данном случае ping 192.168.99.1 с клиента iodine и 192.168.99.2 с сервера iodine.
Данные внутри туннеля — только IPv4.
По умолчанию сервер прослушивает входящие запросы как по IPv4, так и по IPv6. Используйте опции -4 или -6, чтобы слушать только один протокол. «Сырой» режим будет использоваться по тому же протоколу, который применялся при входе.
Клиент может использовать IPv4- или IPv6-неймсерверы для подключения к iodined. Ретранслирующие неймсерверы при необходимости автоматически преобразуют протоколы. Используйте опции -4 или -6, чтобы заставить клиента применять конкретную версию IP для своих DNS-запросов.
Если ваш сервер слушает IPv6 и доступен, добавьте для него запись AAAA в вашу DNS-настройку. Расширение примера выше будет выглядеть так:
t1 IN NS t1ns.mydomain.com. ; note the dot!
t1ns IN A 10.15.213.99
t1ns IN AAAA 2001:db8::1001:99
Можно маршрутизировать весь трафик через DNS-туннель. Для этого сначала добавьте маршрут до хоста-неймсервера, используемого iodine, через проводной/беспроводной интерфейс со шлюзом по умолчанию. Затем замените шлюз по умолчанию на IP-адрес сервера iodined внутри DNS-туннеля и настройте сервер для работы с NAT.
Однако учтите, что передаваемые по туннелю данные вообще не шифруются, и посторонние могут относительно легко прочитать или изменить их. Для максимальной безопасности запустите VPN через DNS-туннель (=двойное туннелирование) или используйте доступ по защищённой оболочке (SSH), возможно, с пробросом портов. Последнее также можно использовать для веб-сёрфинга, запустив веб-прокси (например, Privoxy) на вашем сервере.
Сервер iodined отвечает на NS-запросы, отправленные для поддоменов туннельного домена. Если ваш поддомен iodined — t1.mydomain.com, отправьте NS-запрос для foo123.t1.mydomain.com, чтобы проверить, работает ли делегирование. dig — хороший инструмент для этого:
% dig -t NS foo123.t1.mydomain.com
ns.io.citronna.de.
Кроме того, сервер iodined ответит на запросы, начинающиеся с 'z', для любого из поддерживаемых типов запросов, например:
dig -t TXT z456.t1.mydomain.com
dig -t SRV z456.t1.mydomain.com
dig -t CNAME z456.t1.mydomain.com
Ответ во всех этих случаях должен выглядеть как бессмысленный текст.
В Mac OS X 10.6 и новее iodine поддерживает встроенные в ОС собственные устройства utun — используйте -d utunX.
Размер фрагмента DNS-ответа обычно определяется автоматически для достижения максимальной пропускной способности. Чтобы принудительно задать конкретное значение (и ускорить работу), используйте опцию -m.
DNS-имена обычно используются вплоть до их максимальной длины — 255 символов. Было обнаружено, что некоторые DNS-ретрансляторы отвечают на запросы полной длины довольно ненадёжно, давая сильно различающиеся (и в основном очень плохие) результаты автоматического определения размера фрагмента при повторных попытках. В таких случаях используйте переключатель -M, чтобы уменьшить длину DNS-имени, например до 200 символов, что делает эти DNS-ретрансляторы гораздо стабильнее. Это также полезно для некоторых «деоптимизирующих» DNS-ретрансляторов, которые заполняют ответ двумя полными копиями запроса, оставляя очень мало места для нисходящих данных (и не поддерживают EDNS0). Переключатель -M позволяет обменять часть восходящей пропускной способности на нисходящую. Обратите внимание, что минимальное значение -M составляет около 100, поскольку протокол может разбивать пакеты (максимум 1200 байт) только на 16 фрагментов, что требует как минимум 75 реальных байт данных на фрагмент.
Восходящие данные отправляются в gzip-сжатом виде, закодированные Base32; или Base64, если ретранслятор поддерживает смешанный регистр и символ + в доменных именах; или Base64u, если вместо этого поддерживается _; или Base128, если поддерживаются символы с высокими значениями байтов. Это кодирование восходящих данных определяется автоматически. Протокол DNS допускает один запрос на пакет, и один запрос может содержать максимум 256 символов. Каждая часть доменного имени может содержать максимум 63 символа. Поэтому ваше доменное имя и поддомен должны быть как можно короче, чтобы обеспечить максимальную пропускную способность восходящего канала.
Поддерживается несколько типов DNS-запросов; ожидается, что типы NULL и PRIVATE обеспечат наибольшую нисходящую пропускную способность. Тип PRIVATE использует значение 65399 из диапазона частного использования. Другие доступные типы: TXT, SRV, MX, CNAME и A (возвращающий CNAME), в порядке убывания пропускной способности. Обычно «лучший» тип запроса определяется автоматически и используется. Однако DNS-ретрансляторы могут накладывать ограничения, например на NULL и TXT, из-за чего на самом деле лучшим выбором становятся SRV или MX. Это не определяется автоматически, но можно принудительно задать с помощью опции -T. Рекомендуется пробовать различные альтернативы, особенно когда автоматически выбранный тип запроса даёт нисходящий размер фрагмента менее 200 байт.
Обратите внимание, что запросы SRV, MX и A (возвращающие CNAME) могут/будут вызывать дополнительные обращения «умных» кэширующих неймсерверов для получения фактического IP-адреса, что может либо замедлить работу, либо полностью привести к сбою.
DNS-ответы на запросы, отличные от NULL/PRIVATE, могут быть закодированы тем же набором кодеков, что и восходящие данные. Обычно это также определяется автоматически, но полного исчерпывающего тестирования не проводится, поэтому при выборе более продвинутых кодеков некоторые проблемы могут остаться незамеченными. В этом случае вы увидите сбои/повреждения при автоматическом определении размера фрагмента. В частности, было обнаружено, что некоторые DNS-ретрансляторы переводят ответы, возвращающие имена хостов (SRV, MX, CNAME, A), в нижний регистр только когда это имя превышает ок. 180 символов. В этих и подобных случаях используйте опцию -O, чтобы попробовать другие нисходящие кодеки; Base32 должен работать всегда.
Обычный режим работы теперь подразумевает, что сервер не отвечает на DNS-запрос, пока не поступит следующий DNS-запрос, — так называемый «ленивый» режим. Таким образом, у сервера всегда под рукой будет DNS-запрос, когда необходимо отправить новые нисходящие данные. Это значительно улучшает (интерактивную) производительность и задержку, а также позволяет замедлить фоновые ping-запросы до интервалов в 4 секунды по умолчанию, а возможно, и гораздо медленнее. По сути, основное назначение ping-запросов теперь — принудительно получить ответ на предыдущий ping и предотвратить тайм-ауты DNS-сервера (обычно не менее 5–10 секунд согласно RFC1035). Некоторые DNS-серверы более нетерпеливы и будут выдавать ошибки SERVFAIL (тайм-ауты) в периоды отсутствия туннельного трафика. Однако все данные всё равно должны проходить, но iodine всё равно уменьшит интервал ping до 1 секунды (-I1), чтобы сократить количество сообщений об ошибках. Это может не помочь для очень нетерпеливых DNS-ретрансляторов, таких как dnsadvantage.com (ultradns), которые дают тайм-аут за 1 секунду или даже меньше. Тем не менее данные всё равно будут проходить, и вы можете игнорировать ошибки SERVFAIL.
Если вы работаете в локальной сети без промежуточного DNS-сервера, попробуйте -I 50 (iodine и iodined закрывают соединение после 60 секунд тишины). Единственный случай, когда вы заметите замедление, — это пропажа пакетов с DNS-ответами; тогда серверу iodined приходится ждать нового ping, чтобы повторно отправить данные. Вы можете ускорить это, создав немного восходящего трафика (нажатие клавиши, ping). Если это происходит часто, проверьте сеть на узкие места и/или запустите с -I1.
Задержка ответа в «ленивом» режиме приведёт к тому, что некоторые коммерческие DNS-ретрансляторы «операторского класса» будут многократно повторно отправлять один и тот же DNS-запрос на сервер iodined. Если DNS-ретранслятор на самом деле реализован как пул параллельных серверов, дублирующиеся запросы могут даже приходить из нескольких источников. Этот эффект будет заметен только в сетевом трафике на сервере iodined и не повлияет на соединение клиента. Iodined заметит эти дубликаты и отправит один и тот же ответ (когда наступит его время) и на исходный запрос, и на последний дубликат. После этого полный ответ кэшируется на короткое время. Задержанные дубликаты, которые приходят на сервер ещё позже, получают ответ, который клиент iodine проигнорирует (если он вообще туда дойдёт).
Если у вас возникли проблемы, попробуйте изучить трафик с помощью инструментов мониторинга сети, таких как tcpdump или ethereal/wireshark, и убедитесь, что ретранслирующий DNS-сервер не закэшировал ответ. Закэшированное сообщение об ошибке может означать, что вы запустили клиент раньше сервера. Опция -D (и -DD) на сервере также может показывать полученные и отправленные запросы.
Если порт 53 на конкретном интерфейсе занят приложением, которое его не использует, укажите в iodined опцию -p для задания альтернативного порта (например, -p 5353) и используйте, скажем, iptables (в Linux) для перенаправления трафика:
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to :5353
(Прислано Tom Schouten)
Iodined отклоняет данные от клиентов, которые не проявляли активности (данные/ping) более 60 секунд. Аналогично, iodine завершает работу, если в течение 60 секунд не получено нисходящих данных. В случае длительного обрыва сети или чего-то подобного просто перезапустите iodine (повторный вход), возможно, несколько раз, пока не получите обратно свой прежний IP-адрес. После этого просто подождите некоторое время, и вы в конечном итоге увидите, как туннельный TCP-трафик продолжит передаваться с того места, где он остановился до обрыва.
С введением очереди нисходящих пакетов на сервере его использование памяти увеличилось на несколько мегабайт в конфигурации по умолчанию. Для использования в средах с малым объёмом памяти (например, при запуске на вашем DSL-роутере) вы можете уменьшить USERS и убрать определение OUTPACKETQ_LEN в user.h без каких-либо негативных последствий, если в любой момент времени будет подключён максимум один клиент. Небольшое значение DNSCACHE_LEN по-прежнему рекомендуется, желательно 2 или выше; впрочем, вы также можете убрать его определение, чтобы сэкономить ещё несколько килобайт.
Один сервер iodine может обслуживать несколько доменов. Настройте различные NS-записи в одном домене, указывающие на один и тот же хост, и используйте подстановочный знак в начале аргумента верхнего домена (пример *.mydomain.com). iodine будет принимать туннельный трафик для всех доменов, соответствующих этому шаблону. Подстановочный знак должен находиться в начале аргумента верхнего домена и за ним должна следовать точка.
В этом разделе приведены некоторые результаты измерений производительности. Для правильного отображения используйте моноширинный шрифт, например Courier.
Измерения проводились в протоколе 00000502 в «ленивом» режиме; кодирование восходящих данных всегда Base128; iodine -M255; iodined -m1130. Сетевые условия были не слишком благоприятными; результаты — это не эталонные тесты, а реалистичная оценка производительности в реальных условиях, которую можно ожидать в похожих ситуациях.
Пропускная способность восходящего/нисходящего канала измерялась путём копирования по scp файла, предварительно прочитанного из /dev/urandom (т.е. несжимаемого), и измерения размера с помощью ls -l ; sleep 30 ; ls -l по отдельному нетуннельному соединению. Учитывая большой размер блока scp в 16 кБ, это даёт разрешение 4,3 кбит/с, что объясняет, почему некоторые значения точно совпадают. Времена кругового пути ping измерялись с помощью ping -c100; приведены средний rtt и среднее отклонение (показывающее разброс вокруг среднего), в миллисекундах.
Laptop -> Wifi AP -> Home server -> DSL provider -> Datacenter iodine DNS "relay" bind9 DNS cache iodined
downstr. upstream downstr. ping-up ping-down
fragsize kbit/s kbit/s avg +/-mdev avg +/-mdev
-----------------------------------------------------------------------------
iodine -> Wifi AP :53
-Tnull (= -Oraw) 982 43.6 131.0 28.0 4.6 26.8 3.4
iodine -> Home server :53
-Tnull (= -Oraw) 1174 48.0 305.8 26.6 5.0 26.9 8.4
iodine -> DSL provider :53
-Tnull (= -Oraw) 1174 56.7 367.0 20.6 3.1 21.2 4.4
-Ttxt -Obase32 730 56.7 174.7*
-Ttxt -Obase64 874 56.7 174.7
-Ttxt -Obase128 1018 56.7 174.7
-Ttxt -Oraw 1162 56.7 358.2
-Tsrv -Obase128 910 56.7 174.7
-Tcname -Obase32 151 56.7 43.6
-Tcname -Obase128 212 56.7 52.4
iodine -> DSL provider :53
wired (no Wifi) -Tnull 1174 74.2 585.4 20.2 5.6 19.6 3.4
[174.7* : these all have 2frag/packet]
Laptop -> Wifi+vpn / wired -> Home server iodine iodined
downstr. upstream downstr. ping-up ping-down
fragsize kbit/s kbit/s avg +/-mdev avg +/-mdev
-----------------------------------------------------------------------------
wifi + openvpn -Tnull 1186 166.0 1022.3 6.3 1.3 6.6 1.6
wired -Tnull 1186 677.2 2464.1 1.3 0.2 1.3 0.1
Производительность сильно зависит от низких значений ping, поскольку iodine требует подтверждения для каждого фрагмента данных, прежде чем перейти к следующему. Разрешение нескольких фрагментов одновременно, как в TCP, могло бы повысить производительность, но, скорее всего, привело бы к серьёзной перегрузке промежуточных DNS-серверов. Текущий протокол масштабирует производительность в зависимости от отзывчивости DNS, поскольку DNS-серверы в среднем обрабатывают не более одного DNS-запроса на клиента.
iodine протестирован на Linux (arm, ia64, x86, AMD64 и SPARC64), FreeBSD (ia64, x86), OpenBSD (x86), NetBSD (x86), MacOS X (ppc и x86, с http://tuntaposx.sourceforge.net/) и Windows (с драйвером OpenVPN TAP32, см. файл readme для win32). Его должно быть легко портировать на другие unix-подобные системы с поддержкой туннелирования TUN/TAP. Сообщите нам, если вам удастся запустить его на других платформах.
Название iodine было выбрано потому, что оно начинается с IOD (IP Over DNS — IP поверх DNS), а также потому, что у йода атомный номер 53, который как раз является номером порта DNS.
Copyright (c) 2006-2014 Erik Ekman [email protected], 2006-2009 Bjorn Andersson [email protected]. Также крупный вклад Анны Беземер (Anne Bezemer).
Разрешается использовать, копировать, изменять и/или распространять это программное обеспечение в любых целях, с оплатой или без неё, при условии, что вышеуказанное уведомление об авторских правах и этот текст разрешения будут включены во все копии.
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПРЕДОСТАВЛЯЕТСЯ «КАК ЕСТЬ», И АВТОР ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ В ОТНОШЕНИИ ЭТОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, ВКЛЮЧАЯ ВСЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ КОММЕРЧЕСКОЙ ПРИГОДНОСТИ И ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ. НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ АВТОР НЕ НЕСЁТ ОТВЕТСТВЕННОСТИ ЗА ЛЮБОЙ ОСОБЫЙ, ПРЯМОЙ, КОСВЕННЫЙ ИЛИ ПОБОЧНЫЙ УЩЕРБ, А ТАКЖЕ ЗА ЛЮБОЙ УЩЕРБ, ВОЗНИКШИЙ В РЕЗУЛЬТАТЕ ПОТЕРИ ДАННЫХ, ПРИБЫЛИ ИЛИ ИСПОЛЬЗОВАНИЯ, НЕЗАВИСИМО ОТ ТОГО, ИМЕЕТ ЛИ МЕСТО ИСК ИЗ ДОГОВОРА, ГРАЖДАНСКОГО ПРАВОНАРУШЕНИЯ ИЛИ ИНОГО ДЕЙСТВИЯ, ВОЗНИКШИЙ В СВЯЗИ С ИСПОЛЬЗОВАНИЕМ ИЛИ ПРОИЗВОДИТЕЛЬНОСТЬЮ ЭТОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.
Реализация MD5 — Л. Питер Дойч (лицензия и исходный код в src/md5.[ch])
Copyright (C) 1999, 2000, 2002 Aladdin Enterprises. Все права защищены.