Задача: получить интернет (легальным?) методом посредством туннелирования его через DNS.
Решение: linux+ iodine + routing + NAT + squid, и всё это под управлением network manager'а.
В статье: описание организации DNS туннеля посредсредством программы iodine, нюансы организации маршрутизации через образовавшийся туннель, самописный помощник для iodine и network manager.
Лирика: Занесла меня судьба на славный остров Кипр, кой славен своим П/пафосом, фраппэ и таким интернетом, после которого российские опсосы начинают выглядеть ангелами во плоти. В частности, попытка подключиться к интернетам закончилась ожиданием, что местный провайдер (Сyta) смилостивится, таки закончит пить оный фраппэ и дотянет до меня поганый ADSL 4Мб/768кбит всего-навсего за €151 (подключение) + €40 в месяц (за 4 мегабита! >_<). Ожидание тянулось и тянулось (как бы уже третья неделя пошла), а рядом был славный PrimeTel, который предлагал за €4/час (172р/час) осчастливить меня интернетом прямо тут и сейчас через едва видный WiFi. Я бы даже и согласился, но видна точка доступа была только на балконе, а в квартире связь была нестабильной и часто терялась. Так что оставалось одно решение (помимо взлома WEP-сети соседей, что уж совсем уголовщина) — это злоупотребить сервисом DNS, который безвозмездно, то есть даром, предоставляет PrimeTel для своих незарегистрировавшихся подлюченцев.
Те, кому интересно «howto» — решение далее по тексту, а пока что начнём с теории процесса.
DNS tunneling
Если у нас под руками есть работающий DNS-ресолвер (то есть сервер DNS с включенной рекурсией), то он может на наш запрос об IP-адресе узла foobar.example.com пойти на .com, узнать там адрес сервера, отвечающего на example.com, пойти на example.com, уточнить кто отвечает за foobar, и у указанного сервера уточнить подробности. Узнавать он может не только IP-адрес (A и AAAA записи), но и кучу другой информации, которая может храниться в DNS. В частности:
- MX — содержит строку с описанием того, кому слать почту для foobar.example.com
- SRV — содержит строку с информацией о том, какие (новые) сервисы есть и по каким адресам — например, её использует джаббер
- TXT — случайная информация в текстовом виде. Чаще всего её на практике используют для SPF (правил, описывающих кто может отправлять почту с домена foobar.example.com).
(тут потерялась 300кб лекция о том, что такое DNS и как он работает).
Для наших нужд из этого вытекает простая вещь: мы можем попросить ресолвер узнать немного информации у foobar.example.com. Ресолвер пойдёт, узнает, закеширует (если мы снова запросим её, то он ответит из кеша) и отдаст нам. Если мы каждый раз будем запрашивать другую запись (для другого имени в этой зоне или другой тип записи), то ресолвер будет послушно ходить и ресолвить. Каждый раз. Заметим, для ускорения процесса он закеширует информацию «к кому ходить за такой-то информацией» и процесс в дальнейшем будет происходить в один хоп.
Ура, канал передачи информации от сервера к нам есть. А обратно? Но мы же можем попросить узнать у example.com не foobar.example.com, а, например,
0ahb282M-J2hbM->M-nYM-VgdM-OJM- CM->M-nivlm4M-T5M-FM-p1M-t5M- fM-uM-IvLM-HM-NM-aM-IM-eLAM- BM-TM-qM-KM-UDM-NM-uM-]M-WM- jM-DdbM->M-k.QVM-lM-uM-`v M-@3kGfM-fqFa.example.com
(это один длиииный адрес сайта в интернетах, написанный столбиком для удобства неразрыва ваших френдлент)
Ресолвер пойдёт на example.com и спросит его об этом адресе. А если в адрес закодировано послание? (Криптоложцы встрепенулись — закодированное в имени послание!)
А если?.. Да, именно так. Имя содержит в себе зашифрованное послание. Мы нашли метод передачи информации на сервер. DNS-сервер. Или фальшивый сервер, который притворяется DNS-сервером, а на самом деле слушает зашифрованные в именах послания и отвечает на них зашифрованными посланиями в ответах на запросы.
Другими словами, мы получаем канал передачи данных на сервер и с сервера клиенту через DNS-ресолвер.
На этом принципе основывается работа утилиты iodine. В настоящий момент, по моим наблюдениям, это единственное реально работающее приложение с разумным объёмом настройки.
Настройка iodine
Настройка iodine сводится к трём важным этапам.
Подготовить доменную зону.
Запустить сервер с настройками.
Запустить клиента с настройками.
После этого нам придётся ещё научиться этим каналом пользоваться, но это уже следующая глава.
Итак, начнём со сложного — подготовка DNS.
Настройка в одном предложении: нам надо делегировать на будущий iodine-сервер доменную зону.
Настройка подробно:
Нам надо иметь доступ к администрированию доменного имени. Если домен делегирован на наш сервер — никаких проблем, мы можем прописать в бинде поддомен и делегировать его на iodine-сервер. Если же у нас только «админка провайдера» — то проблема куда более сложная — нужно каким-то образом прописать два поддомена, на одном из них указать NS, указывающую на второй поддомен, который, в свою очередь уже имеет A-запись.
Путано? Давайте ещё раз. Вот пример из моего конфига бинда:
i IN NS j j IN A 256.257.258.259
В нём написано: i.example.com имеет в качестве NS'а сервер j.example.com, который имеет IP-адрес 256.257.258.259.
На хабре есть статья о том, как решить проблему без контроля над доменным именем. Но для настоящего админа не иметь контроля хоть над каким-то доменным именем было бы странно, правда?
Вторая часть — это настройка сервера. Она довольно проста, хотя есть важная деталь: Нельзя запускать iodine на сервере, где работает обычный DNS-сервер. Причина проста — номер порта 53/UDP без права его поменять.
Запуск сервера (iodined) прост:
iodined 10.99.99.1/24 -c i.example.com (нужно указывать имя, для которого мы указали NS, а не имя с 'A' записью. — если этого не сделать, то ресолвер просто не дойдёт до нашего iodine). -c отключает проверку на IP. Я не вникал в подробности, но лучше иметь эту штуку работающей ДО того, как останешься один на один с чужим DNS'ом. Адрес в начале — это адрес в туннеле (tuntap), который будет иметь сервер. Клиенты будут получать следующие адреса (.2, .3 и т.д.).Если запуск iodine скриптуется, то можно ещё добавить пароль:
iodined -P SECRET 10.99.99.1/24 -c i.example.com. Запускать надо от root'а, чтобы iodined мог добавить туннель. В принципе, его можно добавить в rc.local, или просто запустить с & после имени.Важно: версии iodine/iodined должны совпадать. Строго. Иначе связи не будет. Если на десктопе одна версия линукса, а на сервере другая (что типично) — лучше на сервер ставить версию с клиента. Просто скачать deb'ку с репозитория и поставить (благо там зависимостей никаких).
Запуск клиента так же незамысловат:
iodine -P SECRET i.example.com.После соединения мы получаем туннель с адресом, через который доступен удалённый сервер (в нашем случае — 10.99.99.1).
Можно пользоваться.
Можно.
Пользоваться.
А как?
Жизнь в конце туннеля
Если нас интересует что-то, кроме возможности сделать ssh на удалённый сервер, то придётся сделать кучу всего остального. Пост до этого момента был всего лишь художственным объяснением мана. Но практическое использование получившегося туннеля требует от нас решения проблем с сменой шлюза, сохранением «обычного» маршрута для DNS-серверов и преодоление проблем с фрагментированными пакетами.
Если грубо, то есть три метода использования получившегося туннеля:
- Маршрутизация и NAT на сервере
- socks-proxy
- http-proxy (squid)
Разберём их все (и потом уже обсудим как с их настраивать). Основная проблема с маршрутизацией состоит в том, что MTU пакетов, проходящих через сеть, меньше 1500 байт. Много меньше. В зависимости от DNS-сервера не вашего провайдера, которого вы используете (в негативном смысле «использовать»), вы получаете MTU от 1344 (идеальный сценарий) до 740 байт. Другими словами, возникает фрагментация пакетов. А фрагментация пакетов это очень плохо. Это означает, что вероятность потерять пакет увеличивается в 2-3 раза, потому что если вы теряете хвостик пакета, вы его теряете целиком. Плюсом является простота и элегантность решения, а так же zero configuration для всего софта. Включил и работай. А ещё некоторые глупые CDN/IDC у некоторых сайтов блокируют фрагментированные пакеты.
С другой стороны, у нас есть возможность установить TCP-сессию с удалённым сервером (на котором iodined) через туннель, и в этом случае пакеты будут идти с размером MTU туннеля — никакого фрагментирования. Если в этот туннель мультиплексирвать другие tcp-соединения (на уровне потока, то есть sockets), то мы сможем общаться с окружающим миром пакетами такого размера, которые нам подходят. Однако, тут нас ждёт другая подстава. TCP ОЧЕНЬ не любит, когда канал плохой. В чём это выражается? Чем дольше работает TCP на канале с внезапными потерями и повторами, тем меньше он шлёт (считая, что пакеты теряются «из-за перегрузки»). В результате, скорость мультиплексированного канала постепенно падает, падает, падает… В случае если туннелирование происходит через SSH, то на это накладывается ещё и оверхед от шифрования. Где-то через минут десять при плохом DNS проходящие TCP-сегменты можно разглядывать поштучно в tcpdump/wireshark. Ещё одной проблемой являются внезапные задержки с поздними ответами, которые приводят к многочисленным dup ack (я не настолько хорошо знаю TCP, чтобы сказать, плохо это или совсем плохо). Однако, мне не удалось найти настроек ядра для изменения таймаута на перепосылку сегмента в TCP (кроме одиного define'а в сырцах, но до пересборки своего ядра под dns-tunnel я не успел дойти — интернет таки подключили, и интерес в развитии вопроса немного отпал). Заметим, это единственный способ, который можно использовать, если на удалённом сервере лучше никаких крупных изменений не вносить. В этом случае мы подключаемся к серверу командой
ssh -CD 1080 10.99.99.1, прописываем socks-proxy в браузере на 127.0.0.1:1080 и имеем доступ в интернет. Из браузера. Только. Остальной софт настраивать соответствующе.В принципе, для части программ может помочь утилита tsocks, принудительно заворачивающая трафик от приложения в socks-proxy. Используется она так: прописать в /etc/tsocks.conf правильный адрес прокси (127.0.0.1, port 1080, напоминаю), после чего запускать
tsocks my_net_appication app-arguments.Есть ещё один, более любопытный метод: мы можем поднять squid на сервере с iodined, сказать ему слушать на iodined интерфейсе (или на всех — но с acl'кой по адресам туннеля) и использовать нешифрованные соединения между клиентом и сервером. Таким образом мы получаем во-первых нефрагментированные пакеты, а во-вторых имеем множество TCP-сессий, которые сильно меньше подвержены деградации из-за кратковременных лагов DNS-сервера.
Минусов два: во-первых у нас нет сжатия (ssh умеет жать трафик, то есть все передаваемые заголовки в http оказываются отлично пожаты), во-вторых ssl проходит «как есть» или не проходит вообще.
Жизнь в начале туннеля: iodine-mn-helper
Ещё одной проблемой является конфигурирование шлюза по умолчанию в туннеле. Поскольку squid — http-only, то маршрутизацию для всего остального (почта по IMAP, Jabber, etc) нужно делать через NAT.
Проблемой является организация шлюза по умолчанию. Суть проблемы — если у нас dns-сервера находятся не в выданном нам сегменте (например, нам выдали 5.10.10.10/24, а DNS-сервера в 5.11.11.22 и 5.11.12.33), то если мы поменяем шлюз по умолчанию, то потеряем связь с DNS-серверами.
Определение текущих DNS-серверов так же довольно занудно. После некоторых мучений, я написал скрипт-хэлпер: github.com/amarao/iodine-nm-helper
Он весьма несовершенен, и дальнейшие улучшения приветствуются. Но он явно удобнее, чем скрипт iodine-client-start (прилагается к пакету с iodine), который не умеет разруливать проблемы c DNS.
Скрипт рассчитан на использование NetworkManger'а. К сожалению, повторый самоперезапуск скрипта после обновления аренды DHCP я не осилил, так что каждый раз, когда обновляется аренда, маршрутизация ломается и скрипт надо перезапускать.
Производительность и качество связи
Досточтимые ценители халявы, спешу разочаровать. DNS tunnels в реальных условиях (вне лаборатории) очень медленный и заменой нормального интернета не являются. Даже edge от tele2, уж насколько тормозной, и то быстрее. Снизу картинка из firebug'а при открытии github'а. Узрите и прослезитесь — это минуты загрузки, всё именно так и есть.
Скорость меняется крайне неравномерно. Я потратил некоторое время на изучение происходящего с tcp при работе через туннели — в силу специфичного поведения, наблюдается множество ретрансмитов и duplicate ack'ов, то есть tcp не может приспособиться к крайне неравномерной latency, когда любой пакет может «затупить» на единицы секунд, а может пройти за несколько десятков/сотен милисекунд.
В качестве минимального «что-то вместо ничего» он может использоваться. Например, в пике download'а (эм… гигантский файл в 1.6Мб размером) я наблюдал скорость до 8кб/с, но она быстро упала до нуля, и процесс пришлось несколько раз перезапускать. Если добрая cyta меня таки не подключит в ближайшие дни, то я зароюсь в дебри TCP чуть поглубже, чтобы найти эту заветную «retransmission timeout».
Проблема с dhcp. В PrimeTel у DHCP маленький срок аренды. При этом, при обновлении аренды происходит автоматическое обновление и маршрутов, то есть наш шлюз по умолчанию заменяется на паймтеловский. Почесав в затылке, я решил, что маршрут на сеть 0.0.0.0/0 (упс, поделил на ноль снова) будет круче. При этом остаётся проблема пропадающих маршрутов до DHCP, решения которой я пока не придумал (адреса выдают из разных сетей, в каждой такой сети свой шлюз, так что прибитые гвоздями маршруты не годятся, а прихватизировать адрес в чужой сети статикой я посчитал неэтичным и нарушающим правила пользования сетью).
Так что вопрос, вообще говоря, открытый.
Вопрос легальности
Наверное, самый сложный из. Формально, я получаю то, что не должен был получить, не заплатив за это много-много-много евро. С другой стороны, доступ к своим DNS-серверам оператор WiFi хотспота открыл добровольно и осознанно. Как именно я использую сервис — это уже мои проблемы, важно, что я не осуществляю никакого рода взломов (например, подбор пароля — уже очевидная уголовщина, несанкционированный доступ к вычислительной системе).
Полагаю, что этот вопрос находится в серой зоне (то есть точка зрения зависит от скилла адвоката в суде). В реальной же жизни — всем пофигу. Точнее, оператору может быть не пофигу, если его DNS сервера навернутся, но пока оно работает — никаких проблем. В свете тех фантастических скоростей, которые показывает iodine, всерьёз обсуждать «утрату» сотни килобит трафика даже не получается. В принципе, самое неприятное для оператора в данном случае это нагрузка на DNS и паразитный трафик в wifi-сети.
Настройки
(дальше скучно для всех, кроме тех, кто будет настраивать).
На сервере:
sysctl net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.99.99.0/24 -j MASQUERADE
iodined -P SECRET 10.99.99.1/24 -c i.example.com
На клиенте:
vim /etc/iodine-nm-helper.conf (добавить настройки)
./iodine-nm-helper
(скрипт поправит маршрутизацию через туннель)
В firefox'е выставить http-прокси через ip сервера туннеля.
Конфиг сквида:
acl good src 10.99.99/24
http_access allow good localhost
http_access deny all
Комментарии (75)
f1045
30.12.2013 11:50Экспериментировал ли с разными видами CONFIG_TCP_CONG?
И ещё интересно с точки зрения провайдера — насколько заметно это мешает (забивает кэш днс-сервера мусором?) и есть ли хороший способ защититься (в лоб — резать запросы длиннее n байт, но это как-то грубо)
unxed
30.12.2013 11:50Есть такой ключик iodine: -M число
Как раз ограничивает длину запроса, если провайдер режет длинные.
link0ln
30.12.2013 11:50>>я наблюдал скорость до 8кб/с
Я выжимал честных аж полмегабита, вполне юзабельно по wifi, через edge или 3g возможно будет хуже.
anonymous
30.12.2013 11:50
amarao Автор
30.12.2013 11:50В лаборатории (читай, на своих DNS'ах) я получал сервис, который было трудно отличить от обычного. Но полевые испытания показали, что не всё так хорошо. Больше всего tcp стадает от внезапного jitter'инга ресолверов — идут пачками дупликаты и ретрансмиты.
nzeemin
30.12.2013 11:50помимо взлома WEP-сети соседей, что уж совсем уголовщина
Интересная логика.
Взлом WEP значит уголовщина, а получение сервиса через DNS туннель типа — нет.amarao Автор
30.12.2013 11:50Получение сервиса DNS через публичный DNS это не уголовщина. А вот что именно я ресолвлю и зачем — мои личные проблемы.
Сравните с взломом WEP'а. Сам взлом никого не волнует, а в момент подключения с чужими данными я вторгаюсь в чужую сеть, которая была закрыта табличкой «не входить, шифровано».
maverickcy
30.12.2013 11:50На взломе WEP мы заработали на кипре с другом много, и до сих пор зарабатываем, потому что есть уже много «умельцев». Кстати, WEP- это не всё еще. Пролистайте список сетей и найдите сеть вида CYTA11FFAA — есть алгоритмы и даже програмки, которые эти алгоритмы реализуют, которые по SSID вычисляют возможные дефолтные ключи WEP/WPA.
Никого такой взлом не парит на кипре, я общался с главным чуваком по связям в самой CYTA, Они даже не верят, что взлом возможен. Так что, вскрывайте и не парьтесь — 5 лет этим тут занимаюсь. Вы еще в Пафосе?
Тут есть еще PrimeTel DSL с ценой 32 евро/8Mbit безлимит. ПОдключение 150 тоже.
Еще есть CableNet, который за 30 евро дает 12мбит/c безлимит.
В лимассоле CableNet вообще дает 100мбит/c за 100 евро в месяц, что для кипра очень круто.
Но не знаю пока, как он работает. У самого сеть с выходом в 32мбитс от PrimeTel, плачу 70 евро.
anonymous
30.12.2013 11:50amarao Автор
30.12.2013 11:50В моём случае это было i.tdhq.org, короче некуда. А вот домена x.ru нету и быть не может.
pansa
30.12.2013 11:50Если очень захотеть — всё может =)
Например, домен d.rw принадлежит одной российской антивирусной компании. Линк-шотенер на нем крутился, из-за небольшого казуса сейчас не доступен, но руки дойдут — восстановим. Не.ру, но смысл в том, что технически это можно.
devpreview
30.12.2013 11:50Один мой знакомый™ творил похожие вещи ещё во времена dial-up'а, когда были специальные номера на которых соединение не тарифицировалось, но предполагался доступ к ограниченному числу сайтов.
icCE
30.12.2013 11:50какой же я видимо старый.
Freeinet for Russin. Сети x25.
SPRINT,Rosnet итд итп.
Вот по быстрому нашел
bugtraq.ru/library/underground/sprint.html
Rulin
30.12.2013 11:50еще была Sita (точно не помню как называлось), тоже юзал ее вместе с Sprint
Pugnator
30.12.2013 11:50Sita — о да, дозвон по скриптам, вечно забитый пул и раздача скриптов по личкам на форумах…
А ещё openwww в Москве. На куче сайтов были форумы — общались. А ещё куча дырок и туннелинг процветал… были времена…
pansa
30.12.2013 11:50А еще было — нащупали баг в веб интерфейсе провайдера «РОЛ» чтоли, и можно было «честно» выигрывать 1-часовые карточки качественного диаплап доступа в интернеты… Ух.
ragus
30.12.2013 11:50да, я в этой всей фигне учавствовал :) Курпан теперь музыкант группы «Черный Кузнец» :)
reji
30.12.2013 11:50Существуют способы блокировки «неправедных» DNS-резолвов для хотспотов.
Вопрос в том, хорошо или плохо то, что многие интеграторы забывают/забивают на нее? )amarao Автор
30.12.2013 11:50Если не секрет, то какие? Как отличить легитимное имя от трафика туннеля?
Lefty
30.12.2013 11:50Выставить определенную планку для DNS pps rate, при туннелировании очевидно что он в разы выше обычного use case.
amarao Автор
30.12.2013 11:50Для обеспечения 8 килобайт в секунду достаточно 8 запросов в секунду. К разным поддоменам одного домена. Вы действительно хотите ограничить com.ru или co.uk меньшей величиной частоты запросов?
Lefty
30.12.2013 11:50Можно повесить детектилку аномалий — парсить поле name в dns query пакетах и если стабильно преобладают запросы, в которых это поле имеет максимальную длину — склеивать такому клиенту ласты. Воощем если сильно надо, то можно что-нибудь придумать.
Ну а в целом, да, dns — лучший вариант организовать скрытый канал связи. Много где никто особо не заботься о том, чтобы применять какие-то egress fw фильтры к dns, даже там, где работают DLP-системы.amarao Автор
30.12.2013 11:50Грубо, напоминает ранние модели антиспама, где ради подавления спама сильно теряли обычные письма (а чё тут такого, 0.5% — низкий показатель).
reji
30.12.2013 11:50На хотспотах стоят свои кэширующие DNS-сервера. Запретить для неавторизованных пользователей трафик до 53 порта к любому хосту кроме легитимного. Метод «топора», но эффективно.
sergey_dobrodey
30.12.2013 11:50Нельзя не упомянуть ICMP tunnel
amarao Автор
30.12.2013 11:50… который чаще всего не доступен, т.к. режут весь трафик из сети.
sergey_dobrodey
30.12.2013 11:50В годах так 2010-2011 у минского провайдера «НИКС» приходилось использовать. Каково положение сейчас — не знаю.
Ну а в большинстве случаев всё верно, icmp тоже режут.
mrsom
30.12.2013 11:50>Суть проблемы — если у нас dns-сервера находятся не в выданном нам сегменте (например, нам выдали 5.10.10.10/24, а DNS-сервера в 5.11.11.22 и 5.11.12.33), то если мы поменяем шлюз по умолчанию, то потеряем связь с DNS-серверами.
policy-routing habrahabr.ru/post/108690/ в этом случае вам помочь не сможет?
Я как-то года три назад немного ковырялся с openvpn тоннелями и была похожая проблема, которую я решил с помощью policy-routing и кажется немного магии iptables тоже было, но на счет деталей ничего сейчас не скажу… Повторно мне всё это не пригодилось, а тогда как-то настроил и забыл.amarao Автор
30.12.2013 11:50Наверное, поможет. Но я про них ничего не знал. Но policy routing требует указания критериев маршрутизации, а какие они могут быть, кроме «весь трафик, кроме DNS-серверов, заворачивать в туннель»? По сути тот же dest routing и получается, а главная проблема — как определить какой трафик не заворачивать.
mrsom
30.12.2013 11:50fwmark – проверка значения FWMARK пакета. Это условие дает потрясающую гибкость правил. При помощи правил iptables можно отфильтровать пакеты по огромному количеству признаков и установить определенные значения FWMARK. А затем эти значения учитывать при роутинге.
Думаю, что по любому гибкости iptables должно хватить, чтобы промаркировать те пакеты, которые нужно завернуть куда нужно.
Именно так у меня оно всё и работало кстати.amarao Автор
30.12.2013 11:50Тыг вся проблема не в том, что «непонятно что с пакетами делать», а в том, что непонятно как пакеты отличить. У network-manager'а в сочетании с dnsmasq'ом просто нет прямого метода узнать dns-сервера, полученные из аренды. Мне пришлось парсить вывод nmcli для выковыривания этих данных. А дальше-то просто: на них прямой роут через провайдера, остальное через туннель.
Я не уверен, что гибкости pwmark'а достаточно для того, чтобы сказать что-то вида «dns-сервера, полученные по dhcp» :)mrsom
30.12.2013 11:50Я не знаю что имеется ввиду под network-manager, но так то в общем если прописать свой какой-нибудь ip-up скрипт нельзя, то что-нибудь запарсить — вполне себе решение. А потом когда уже будут известны эти адреса — гибкости fwmark'а должно хватит.
Кажется я не понимал, что у вас проблема не с самим механизмом роутинга, а с тем чтобы выковыривать dns из dhcp. В этом предложенная мной техника конечно не поможет.
flaer
30.12.2013 11:50Автору нужно узнать, что добрая половина Кипра сидит на соседской cyta. И все гораздо проще:
amigdalo.ath.cx/ST/
www.youtube.com/watch?v=VqmPcCtsqxs
Mediascenter_Thomson_key.rar использует общую дыру (зависимость пароля от имени по умолчанию wifi сети) для всех Thomson роутеров, выпущенных до 11 года кажется. Неоднократно помогала программка.
Cablenet не дошел еще до Пафоса, да? Гораздо приятнее провайдер во всех отношениях, и по ценам и по качеству.amarao Автор
30.12.2013 11:50Ситовские пароли я знаю. Однако, повторю, это нелегально на 100%. Cablenet'а в районе нету.
maverickcy
30.12.2013 11:50никто вас за это не будет бить, и даже слова не скажет — не парьтесь. Мы с другом за это еще и деньги берем.
maverickcy
30.12.2013 11:50Мало минусов, хочу ещё! А то я неправильно что-то комментирую, не то, что все хотят видеть
maverickcy
30.12.2013 11:50Давайте еще минусов! А то меньше чем на предыдущем коментарии!
amarao Автор
30.12.2013 11:50Возможно кому-то всё-таки не нравится идея взлома. Лично моей этике это претит.
maverickcy
30.12.2013 11:50С моей точки зрения это выглядело как помощь соотечественнику. Я даже сейчас перечислю причины, по которым этика в данном случае Вас, как IT специалиста не должна настолько беспокоить.
1) Все модемы с SSID CYTA****** и SpeedTouch****** — это интернет подключенный по безлимитному тарифу. Логично, что за большее количество пользователей не приводит к увеличению счета: он как был 50 евро, так и останется.
2) Судя по тому, что вас устраивает ваше решение, то вы бы и так не скушали много полосы пропускания. Минимальная скорость на сегодняшний день на кипре — 2мбит у DSL. В настройки модема можно зайти и посмотреть его скорость и если вам жалко забирать у человека с 2мбит, то найдите себе модем с 5-N мбит/с.
3) И всё таки, я хотел поддержать соотечественника и успокоить, рассказав про свой опыт. Повторяю, здесь это не карается и модемы принадлежат домашним пользователям. Если вы их не можете вскрыть, следовательно над защитой поработали и вам не дадут влезть в сеть и украть корпоративные данные(Хотя обычно встроенный WiFi отключают и используют внешнюю ТД.)
Или вас так волнует вопрос этики, потому что вы, зайдя в чужой Wifi начинаете снифать пакеты, себя не контроллируя?
Если вы все еще в пафосе, скажите в каком районе, подумаю как еще вам смогу помочь
Crankoman
30.12.2013 11:50Давно читал об этом, есть много решений. Даже на андройд play.google.com/store/apps/details?id=biz.nijhof.e53Lite
Djulbars
30.12.2013 11:50Странно, нечто подобное делали и в эпоху диал-апа например через некоторых провайдеров, например РОЛ которые бесплатно пускали на свою страничку без лимита и так же не перекрывали DNS.
Я думал с тех пор все провайдеры поумнели, хотя наверное многие кто сейчас работают у провайдеров об этом и не помнят в силу своего малого возраста в то время :).
mafet
30.12.2013 11:50Ещё кстати нужно добавить, dns-тоннели очень критичны к конечному расстоянию до сервера (latency dns-ответов). Такая халява через днс в основном нужна вне дома, когда другие варианты по каким-то причинам не доступны, а инет очень нужен. Если сервер с iodine стоит, к примеру, в москве, то где-нибудь в юго-восточной азии пользоваться уже практически не возможно, какой бы качественный доступ до днс не был на конечной точке.
amarao Автор
30.12.2013 11:50Возможно, да, в этом дело. Я выходил с Кипра (на котором наружу, за пределы острова, иметь latency < 80 почти невозможно), а сервера были в Амстердаме и Питере.
mafet
30.12.2013 11:50и кстати как раз с Кипра я как-то через какой-то вайфай так сидел, когда сервак в мск был. Коннект к icq по двум номерам с дофигищей контактов — около 5 минут. Загрузка странички без картинок — 3-4 минуты.
DinoAsm
30.12.2013 11:50iptables -t nat -A POSTROUTING -s 10.99.99.0/24 -j MASQUERADE
И это все? Так просто? Во всех примерах настройки nat, которые я видел, там еще штук 5 дополнительных параметров, чтобы разрешить трафику идти в обратном направлении. Я явно чего-то не понимаю.amarao Автор
30.12.2013 11:50Т.к. мы не запрещали ничего, то и разрешать нечего. MASQUERADE обеспечивает contracking (то есть правильную замену dest у пришедших пакетов), а дальше оно само, силами маршрутизации до отправителя вернётся.
Много строчек может быть в продакшен-конфигурации, которая рассчитана на компанию. Т.к. делаем это для себя любимого, то можно защитой от самого себя не злоупотреблять.
mafet
30.12.2013 11:50В плане линукса, я что-то ниразу не видел, чтоб нужно было следить за обратным трафиком в плане nat. А для acl достаточного этого правила:
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
009b
30.12.2013 11:50приспособиться к крайне неравномерной latency,
Джиттером (jitter) называют, кажется. Или вы намеренно не добавляли термины в статью?
Над грамотным закрытием такого рода «каналов связи» (без кавычек не могу написать) не думали? Имеется ввиду что-то умнее, чем просто ограничение количества запросов в секунду по домену/сорсу, вам придумалось? Я же верю, что времени поразмыслить без интернета у вас было достаточно.amarao Автор
30.12.2013 11:50Формально любое ограничение будет нарушением RFC, так что no chances. Если же серьёзно — надо не открывать dns наружу, а ресолвить всё в серый адрес с редиректом куда надо. ttl у записи делать 1с.
Потому что это глупость получается, «как мне сделать dns-сервер, который будет рекурсером, но рекурсером не будет?». На любую signature detection в iodine первым делом добавят scrambling.
unxed
30.12.2013 11:50Если не хочется ломать роутинг на клиенте, но хочется использовать не только браузер, делаем так:
1) Ставим на сервере danted (это socks-proxy), чтобы не набирать каждый раз пароль на ssh.
Ограничиваем прием соединений только с интерфейса туннеля. За авторизацию и так отвечает iodine.
http://spycs.ru/os/170-ustanovka-socks5-proksi-servera-na-ubuntu-debian.html
2) На клиенте ставим пакет tsocks
3) В /etc/tsocks.conf пишем IP-адрес сервера туннеля и порт, на котором работает danted
4) Добавляем tsocks перед вызовом проги, которую нужно загнать в туннель. Например,
tsocks apt-get update
Это для софта, который не умеет работать через socks-прокси нативно (apt в mint, например, не умеет).
PS: Используйте второй днс сервер провайдера, он обычно менее нагружен, и другим клиентам мешать не будете.
erlyvideo
30.12.2013 11:50Разве в DNS можно использовать буквы в разном регистре?
amarao Автор
30.12.2013 11:50В DNS — да. В отдельных зонах регистраторы могут устанавливать дополнительные ограничения.
erlyvideo
30.12.2013 11:50сегодня вот проверял по цепочке эрланг — микротик — что-то у оператора нетбайнет — яндекс днс — мой сервер.
Где-то по пути DNS конвертится в нижний регистр.
GeckoPelt
Автор страшный человек :)
luckyredhot
И страшный любитель халявы))
bougakov
Столкновение с любым ненавязчивым южноевропейским сервисом — греческим, итальянским, испанским, болгарским — кого угодно доведёт до осатанения.