Нерозповсюджений спосіб отримання безкоштовного Інтернету - DNS-туннелінг. Причина непопулярності цього способу - необхідність наявності сервера з root-доступом, софт для туннелінга тільки під Unix-системи і вкрай мало інформації про DNS-тунелюванні російською мовою. Все, що ми маємо - це кілька програм і документації англійською мовою. На сьогоднішній день цей спосіб дійсно працює і все описується в статті перевірялося на декількох провайдерів. Випробування пройшли успішно.
програми
Я знайшов кілька програм для цих цілей - udptunnel, utunnel, iproxy і nstx. Перша відпала відразу, так як в процесі читання доків з'ясувалося, що вона инкапсулирует UDP в TCP, а не навпаки. З рештою трьома програмами теж трапився невеликий казус. Справа в тому, що мій локальний комп'ютер працює під Linux, а віддалений сервер під FreeBSD. На даний момент утиліти iproxy і nstx компілюються і працюють тільки під Linux, відповідно серверну частину запустити не вдасться. Програма ж utunnel навпаки працює тільки під FreeBSD, а до моменту написання статті дистрибутива фряхі під рукою не виявилося. Таким чином довелося не зовсім легальго знайти сервер на Linux (спасибі людині, який допоміг з цим, якщо він читає) і тестувати сервер туннелера на ньому.
iproxy
Я почну з iproxy, тому, що вона простіше в роботі, не позбавлена багів і не потребує особливої налаштуванні. Програма це дуже проста - вона просто реалізує TCP over UDP і нічого більше. Процес компіляції та установки програми стандартний:
До речі встановлювати її не обов'язково - можна використовувати прямо з домашнього каталогу. Після того як ви зібрали її на стороні клієнта, командуйте:
iproxy-client -p 33333 -d 53 -u -v -I 123.45.67.89
На клієнтському комп'ютері все готово, переходимо до серверної частини. Перше, що нам потрібно зробити - це підняти проксі-сервер, так як iproxy-server користується послугами локального проксі і передає його результати клієнту. Проксі може бути будь-яким. Бажано, щоб він підтримував метод CONNECT, тоді можна буде використовувати його не тільки для Web. Я використовував проксі-сервер Squid.
Тепер збираємо iproxy точно також, як це було в клієнтської частини і командуємо наступне:
iproxy-server -u -v -p 53 -d 8080
Знову ж пояснюю опції: -u і -v - це все ті ж unicast і verbose mode відповідно, як ми вказували на клієнтській стороні. -p - це UDP-порт, який ми будемо прослуховувати, а -d - це TCP-порт локального проксі-сервера.
В результаті тестування програма показала себе не з кращого боку. Передавати великі пакети при поганих умовах зв'язку (адже це dial-up) вона не здатна. Наприклад, HTTP працює жахливо - скачується кілька кілобайт сторінки і з'єднання обривається. Також я спробував IRC. Якщо постійно базікати або пінгувати себе (через IRC), то зв'язок нормальна, але варто замовкнути на кілька секунд, як з'єднання знову обривається.
nstx
З nstx все трохи складніше. NSTX - це цілий протокол (Nameserver Transfer Protocol), розроблений гарячими німецькими хлопцями Флоріаном Гайнц (Florian Heinz) і Джульеном Остером (Julien Oster). З його допомогою можна здійснити тунель 'IP over DNS'. Так як DNS-протокол не дозволяє передачу даних більше 512 байт, nstx використовує фрагментацію, а також вводить в UDP деякі функції IP і TCP. Крім того відбувається регулярна звірка з боку клієнта (тому, що сервер не може бути ініціатором з'єднання - прим. Ред.).
Для роботи, nstx використовує псевдоінтерфейс Ethertap. Для цього нам потрібні модулі системи.
Насамперед довантажувати ці самі модулі:
insmod netlink_dev
insmod ethertap
Тепер створюємо файл пристрою:
mknod / dev / tap0 c 36 16
Запускаємо псевдоінтерфейс, сконфігурованих на 10.0.0.1 (вставте IP):
ifconfig tap0 10.0.0.1 up
Тепер, то ж саме робимо на серверної частини.
Залишилося запустити наш nstxd на обох сторонах. Спочатку на серверної запускаємо фальшивий сервер імен:
Потім на клієнтської:
nstxd zone.server.com 123.45.67.89
І як же це працює?
Відбувається інкапсуляція даних в DNS-повідомлення і наші дані передаються DNS, до якого ми маємо доступ. DNS провайдера звертається до нашого сервера, який відповідає за зону zone.server.com, а той передає всю інформацію на фальшивий сервер імен, який і повертає потрібний відповідь по тому ж маршруту назад. Таким чином DNS допомагає нам робити те, для чого він не був передбачений спочатку.
Провайдерам варто задуматися над тим, щоб контролювати запити, що передаються первинним DNS в режимі гостьового доступу, а також заборонити правилами фаервола доступ до інших хостам через 53-й UDP порт. Тільки так можна запобігти DNS-туннелирование і як наслідок - небажаний трафік з гостьового логіна.