Последние годы на кроберских форумах с завидным постоянством задается вопрос "А как скрыть ДНС?" или его вариация "Где найти старый аутпост 4.0?". Признаться, эта жвачка изрядно достала, и данная статья - попытка расставить точки над i. Надеюсь, будет полезной, постараюсь все "разжевать". Хотя и не питаю надежды, что количество вопросов заметно уменьшится... Но по крайней мере можно будет позволить себе удовольствие со спокойной совестью "ткнуть носом" обленившегося новичка в качественную статью. 
Раз уж прозвучала такая заявка на качество, начну с того, что из себя представляет DNS и нахрена он нужен. А так как статья расчитана на новичков, буду объяснять совсем на пальцах.
Теория DNS
Domain Name System — система доменных имён. Если совсем коротко и по существу - позволяет определить IP адрес компьютера в сети по его доменному имени.
Допустим, среднестатистический кробер Вася, учащийся в 8-м классе, узнал про такую хорошую и совершенно необходимую вещь, как VPN. "Кру-у-ута-а-а-а...", - сказал себе Вася и, прервав просмотр накарженной порнухи, полез на сайт самого надежного и "пальцастого" VPN-сервиса. Ввел в адресной строке браузера:
[HIDE=15]vpn.mvd.ru
И нажал "Enter". Что произошло? Нет, то что Вася крупно лоханулся к нашему делу отношения не имеет. Нас интересует другое. С одной стороны, понятно что этот сайт размещен на каком-то сервере (компьютере) в Интернете. С другой - каждому известно, что компьютеры в Интернете находят друг друга по IP адресам. То есть по загадочным сериям цифр с точками вроде "95.173.128.124". Спрашивается: какого хрена наш бедный Вася должен запоминать IP каждого сайта? Ведь уже через месяц такой тренировки мозга он поумнеет и перестанет веселить достопочтенную публику своим фееричным идиотизмом. Чтобы этого не случилось, и была придумана DNS.
Теперь разберемся в том, "как оно работает". Понять причину палива после этого будет очень просто.
Если совсем упрощенно, в Интернете есть DNS-сервера. Они хранят записи о том какой IP какому доменному имени соответствует. Например:
Обратите внимание: ip-ping.ru и nslookup.su имеют один и тот же IP адрес 62.152.63.130. Это вполне нормально, т.к. на одном веб-сервере (не путать с DNS-сервером!) может размещаться куча сайтов. В этом случае доменное имя еще и помогает веб-серверу разобраться, какой именно сайт от него требуют.
Все знают, что сайтов в Интернете стало дофига. И почти у каждого сайта свой домен. Понятно, что помнить адреса всех сайтов одному DNS-серверу ну совершенно не в жилу. Поэтому каждый отдельно взятый сервер отвечает только за свой сегмент сети.
Когда компьютеру нужно узнать какому IP адресу соответствует доменное имя mail.ru, он "спрашивает" это у своего DNS-сервера. То есть делает DNS-запрос. Для начала запомните, что DNS-запросы бывают рекурсивные и нерекурсивные. В чем разница, покажу на примере.
Итак, между компьютером кардера Васи (ККВ) и DNS-сервером Васиного Интернет-провайдера (DNS-прова) происходит следующий диалог:
Теперь рассмотрим другой вариант.
В предыдущих вариантах были примеры чисто рекурсивных и чисто нерекурсивных запросов. Но на практике обычно эти варианты комбинируются: компьютер пользователя делает рекурсивный запрос к DNS-серверу своего провайдера, а тот для него начинает "обзванивать инстанции".
На другой день Вася рассказывает своему однокласснику кардеру Пете, какую классную штуку он нашел. И тот (а я чо - лох?! я тоже хочу дрочить через VPN, так оно безопаснее!) лезет на наш многострадальный сайт "лучшего VPN-сервиса для русских кардеров". Т.к. мегакардеры живут рядом, провайдер у них один (и DNS-прова один и тот же).
* Вариант IV - кэширование DNS *
ККП => DNS'у прова:- Привет. Пете нужен сайт vpn.mvd.ru, какой у него IP?
- Как же, как же. Вчера у меня этот домен уже спрашивали, IP вряд ли поменялся: 95.173.128.124.
Как видим, DNS-сервер провайдера обычно запоминает IP адреса доменов на некоторое время. Петя засветился только на DNS'е провайдера. А остальные DNS-сервера про то, что Петя интересовался этим сайтом, не в курсе.
Паливо ДНСа
В механизме работы DNS мы немного разобрались. Конечно, на деле все горазно сложнее, но для нас это не важно. Для нас гораздо важнее, как этот механизм используется, чтобы нас попалить. Так что же нужно злым админам с mvd.ru, чтобы схватить Васю и Петю за жопу?
а) Свой DNS-сервер, который они контролируют. Он будет фиксировать DNS-запросы и стучать админам;
б) Избежать DNS-кэширования, чтобы все запросы проходили на их DNS-сервер;
в) Как-то отличать DNS-запросы Васи от запросов Пети (и еще тысяч других).С пунктом а) все ясно - ставят DNS на своем серваке и регистрируют его в более старших DNS-серверах (зоны .ru или корневых - не важно).
С пунктами б) и в) тоже все просто. Нужно как-то заставить компьютеры посетителей делать уникальные DNS-запросы на сервер mvd.ru. Они не будут повторяться, поэтому их кэширование не имеет значения. И у каждого посетителя они будут разные, поэтому проверить какой запрос сделан каким пользователем тоже очень просто. Нужно только запомнить, какой домен подсовывался Васе, а какой - Пете.
Как же заставить Васю сделать запрос ya-vasya.mvd.ru, а Петю ya-petya.mvd.ru? Ведь они оба будут вводить в браузерvpn.mvd.ru. Элементарно. Достаточно подделать ссылку на любую картинку или CSS-файл (или любой другой файл), которые будут грузиться вместе со страничкой. В HTML-коде страницы, которую покажут Васе, будет строчка:
Если DNS-запрос к провайдеру будет рекурсивным, то на DNS-mvd.ru полезет DNS-прова, и спалят его. Если нерекурсивным, то компьютер пользователя будет сам спрашивать у DNS-mvd.ru IP домена и попалится сам. Все зависит от настройки DNS-сервера провайдера. При этом не важно, используют ли Вася и Петя прокси или нет. В первом случае запрос будет делать провайдер, а у него никаких прокси нет и в помине. Во втором - DNS-запросы обычно идут в обход прокси. Глобальные проксификаторы операционной системы (Proxifier, WideCap) в обычном режиме тоже не помогут: они перехватывают TCP сессии, а DNS-запросы делаются по UDP протоколу.
Паливо VPN'а
Почему при использовании VPN обычно палится DNS VPN'а, а не провайдера? Если не вдаваться в детали, то потому что VPN-соединение считается своего рода "подключением к Интернету по умолчанию". Если ВПН настроен нормально, то его шлюз является основным, внешний трафик идет на него и определение IP сайтов происходит через DNS-сервер VPN-сервиса. Это уже лучше, но еще не изумительно.
Прячем свой DNS за соксом
Гораздо лучше, если вместо DNS VPN'а будет палиться ДНС натянутого поверх него сокса. Почему? Потому что соксы нам для того и нужны, чтобы их палить
Соксы изначально были задуманы для того, чтобы обеспечить взаимодействие сетей, связь между которыми затруднительна. Сокс - своего рода промежуточный сервер, у которого есть доступ к обеим сетям, которые нужно связать. Поэтому в протоколе SOCKS предусмотрели возможность разрешения доменных имен. Для справки: разрешить доменное имя - значит получить его IP адрес.
Значит компьютер Васи сперва через сокс делает DNS-запрос. Определяет IP хоста vpn.mvd.ru. А потом через сокс же работает с этим IP. Так? Нет, не так. Васин компьютер просто кладет на то, какой IP у этого сайта. Он требует от сокса: "Обеспечь мне связь с хостом vpn.mvd.ru!". Остальное - забота сокса. Он сам будет делать DNS-запрос, чтобы определить IP. Логично спросить: а нахрена я рассказываю про эти тонкости? Да просто чтобы стало понятно: компьютер с правильно настроенным соксификатором при работе через сокс DNS-запросов не делает! Это ему просто не нужно. Зато это очень нужно злым админам нехороших сайтов, чтобы нас попалить.
Настраиваем соксификатор
Теперь про то, как настроить соксификатор. Расскажу об этом на примере программы Proxifier - она наиболее удобная из всех, какими я пользовался. В ней предусмотрено два режима работы с DNS: локальный и удаленный. В локальном режиме компьютер сперва сам определяет IP при помощи DNS-сервера своего провайдера. А уже потом подключается к этому IP через сокс. В этом случае палится либо IP компа, либо DNS провайдера, либо DNS ВПНа. А при удаленном разрешении имен все происходит, как описано выше. Соксу передается доменное имя хоста, к которому нужно подключиться. И он сам пытается определить его IP через свой DNS. Именно такой режим нам и нужен.
Открываем окно Proxifier'а, идем в меню Options -> Name Resolution. Видим галочку Choose the mode automatically и быстренько ее снимаем. Выбирать режим автоматически нам ни к чему - выбор будет явно не в нашу пользу. Далее видим переключатель Locally / Try Locally then Remotely / Remotely. Соответственно: Локально / Попробовать сперва локально, если не получилось - удаленно / Удаленно. Нас интересует последний вариант. Ставим переключатель в положение Remotelyи радуемся жизни.
Вот вроде бы и все, проблема решена. И тут у некоторых возникнет вопрос: а нахрена читать дальше? Для них напомню, что Вася тоже радуется жизни... хотя и юзает ментовский ВПН. Камрады, не будьте васями, читайте дальше!
Отсыпьте-ка мне сверхдлинных запросов...
Теперь, когда малолетние онанисты отсеялись, расскажу про парочку ньюансов. Ведь нас все еще могут ухватить за задницу Сами-Знаете-Кто. Догадываюсь, что такой массаж уважаемой публике ни к чему.
Во-первых, операционная система не в курсе гнусных попыток Proxifier'а послать все на... сокс. Процесс перехвата DNS-запроса системы и отправки вместо этого на сокс доменного имени довольно гемморойный. Во-вторых, из-за кривизны различных настроек Проксифаер может не перехватить попытки какой-нибудь программы выйти в сеть. В-третьих, программа может иметь свои средства разрешения имен и нагло игнорировать стандартные средства системы. Или пользователь может просто забыть включить Проксифаер или добавить в него сокс. Короче говоря, несмотря на правильные настройки Proxifier'а, какой-нибудь шальной DNS-запрос все же может проскочить. Как же с этим бороться?
И тут самое время вспомнить, что многие кроберы с упорством, достойным лучшего применения, атакуют форумы с вопросами: "А где взять четвертый Outpost?..". Более молодые с не меньшим упорством переспрашивают: "А зачем именно четвертый?". Вопрос вполне закономерный, так как эта версия уже давным давно устарела и не обеспечивает наилучшей защиты. На что следует поучительный ответ: "В нем есть блокировка сверхдлинных запросов".
Напомню, что обычный DNS-запрос (вроде "скажи мне IP хоста porno.ru") ничем не опасен. Таких запросов сервер ежедневно получает миллионы. И обслуживают такие запросы не DNS-сервера отдельных сайтов, которые можно контролировать, а "главнюки" зоны .ru. Чтобы отличить запрос онаниста Васи от запроса онаниста Пети, нужно чтобы они:
а) попали на шпионящий DNS-сервер
б) отличались друг от другаТо есть имели вид вроде: fb81a4c57d1a781ff.Domain-Zone-of-Our-Spying-DNS-Server.porno.ru. Вот тогда пользователя с ID fb81a4c57d1a781ff можно хватать за яйца. Именно такие запросы называются сверхдлинными. И именно их блокирует Outpost 4.0. НО! Если мне не изменяет память, сверхдлинным считается запрос на разрешение имени домена четвертого уровня и выше. То есть доменное имя css.server.ru не является сверхдлинным, а f7c1b14.css.server.ru - уже сверхдлинное. Так что спешу порадовать любителей четвертого Аутпоста: запрос типа fb81a4c57d1a781ff.google.com заблокирован не будет. А ведь у такого гиганта как Гугл наверняка есть свои низкоуровневые DNS-сервера. И вполне могут шпионить, если настроены для этого. Так что условия а) и б) выполняются. Вы рады? Я тоже рад за вас!
Почему же старина Аутпост кинул нам такую подлянку? Потому что эта блокировка задумывалась как защита от пересылки данных трояном при помощи DNS-запроса. (login-vasya-password-zhopa.hackers.dns.server.com). В более поздних версиях разработчики признали такую защиту неэффективной и отказались от блокировки сверхдлинных запросов. Прикрывать нас от злых админов в погонах разрабы никогда не собирались.
Так что же делать? Для начала в клиническом ужасе кричим "Ааааааааа!.." и начинаем рвать на жопе волосы. А потом вспоминаем, что "компьютер с правильно настроенным соксификатором при работе через сокс DNS-запросов не делает!". И читаем дальше.
Мочим ДНСов
Раз DNS-запросы не нужны, но могут быть опасны, логичнее всего отказаться от них. То есть заблокировать их все. И сверхдлинные, и сверхкороткие, и даже сверхсредние... И в этом нам поможет наш старый добрый Аутпост, который, надеюсь, вы все используете. Ибо сказано было: "И да настанет Судный День у каждой машины, и да пребудет великая боль с ее хозяином в час отречения от истиннаго владыки - Великого Аутпоста"(© "Откровение от Порочного Бориса", писание первое, глава первая - "Начало").
Что из себя представляет DNS-запрос по своей сути, мы уже разобрались. Технически же он выглядит как исходящий трафик по UDP протоколу на порт DNS. Или как исходящее TCP соединение на порт DOMAIN.
Допустим, 95.31.1.83 - это IP DNS-сервера нашего провайдера. Тогда DNS-запрос для Аутпоста будет выглядеть:
Исходящий UDP на 95.31.1.83:53
Исходящий TCP на 95.31.1.83:53(DNS и DOMAIN - это названия 53-го порта для UDP и TCP протоколов соответственно). Их-то нам и надо укокошить. Беда в том, что наш Аутпост про такую сверхзадачу не в курсе. Пока не в курсе Все, что нужно - сделать правила блокировки такого трафика. А делать такие правила удобнее в новых версиях, так как они в этом смысле более гибкие.
Объяснять буду самый простой способ. Он не самый удобный, но его проще и быстрее всего объяснить. Кто хочет лучшего - разберется.
Открываем окно Аутпоста (например, 2009). Настройки -> Брандмауэр -> Сетевые правила -> Системные правила. Должно появится окошко со вкладкой Глобальные правила. В других версиях интерфейс может быть другой, но окно настройки глобальных правил в нем есть. Ищите.
Видим список глобальных правил, разделенных на две категории: Применяются до правил для приложений, Применяются после правил для приложений. Вторая категория нам не интересна: правила какого-нибудь приложения могут разрешать для него DNS-запросы. И наткнувшись на это правило Аутпост разрешит этой программе сделать DNS-запрос. А нам нужно, чтобы Аутпост сперва наткнулся на наше запрещающее правило. Так уж он устроен: нашел первое подходящее правило - применяет, дальше не смотрит.
Тыкаем кнопку "Добавить".
Первое окошко - событие, в нем выбираем "Где направление" и "Где удаленный порт".
В третьем окошке "Расшифровка правила" появится: "Где протокол TCP и направление Не определено и удаленный порт Не определен, разрешать". Кликаем по TCP, выбираем "UDP". Если в первом окошке какие-то галочки соскочили, ставим по новой.
Аналогично в направлении указываем "Исходящее".
Потом тыкаем по Не определен в пункте "Удаленный порт". В появившемся окне ищем порт DNS (53) и дважды кликаем. Жмем "Ок".
Теперь щелкаем по Разрешать, чтобы оно сменилось на "Блокировать".
Так выглядит правило "Блокировать исходящие UDP на 53-й порт". Или, говоря по-человечески "Блокировать исходящие DNS-запросы"
Еще одна маленькая, но приятная деталь. В окошке 2 "Параметры правила" поставьте галочку Оповещать. Зачем? Чтобы вы не материли бедного Бориса каждый раз, когда забудете включить Proxifier, добавить в него сокс или сокс умрет и у вас тупо не будут открываться сайты. Каждый раз при срабатывании правила внизу будет появляться всплывающее окошечко с сообщением. И будет понятно, что Интернет не работает из-за блокировки DNS-запросов. Окошки эти появляются обычно в самый неподходящий момент, когда вы что-то куда-то вводите. Так что материть меня и Аутпоста вы все равно будете, но уже за сбитый с поля ввода фокус. Но мне оно так приятнее...
Верно настроенное правило выглядит так:
Жмем Ок. В окне с глобальными правилами выделяем строчку с нашим правилом. И топим кнопку "Вверх", пока оно не поднимется на самую верхушку списка. Для тех, кто в танке: галочка напротив правила должна стоять.
Точно так же делаем второе правило, но в нем вместо протокола UDP оставляем TCP. Все остальное так же, только 53-й порт будет называться "DOMAIN". Ставим его вторым в списке.
Все, теперь все попытки сделать DNS-запрос будут пресечены. За исключением запроса на нестандартный порт. Но система делать такого не будет, только какая-нибудь хитроумная программа, а это уже тема совсем другого разговора.
Не ругайте Борьку!
Теперь поговорим про тех, кто все настроил, и у кого ничего не получилось. То есть про тех, кто пытался сделать все как я сказал, но в четвертом Аутпосте, поленившись поставить новую версию. А также про самых внимательных, которые мерзким голосом заметят: "хорошо, при работе через сокс DNS-запросы не нужны... но где взять сокс, ведь для этого сперва нужно зайти на сайт сокс-сервиса?!"
На это отвечу: "Негоже сетовать на судьбу и Господа, коли очаг страстей и рукоблудия созидает Человек в своем Незнании истинных Законов, дарованных нам Великим Аутпостом!"(© "Откровение от Порочного Бориса", писание первое, глава первая - "Начало"). (Вася, Петя, привет!)
В четвертом Аутпосте нет разделения глобальных правил на применяющиеся до и после правил для приложений. Его глобальные правила применяются всегда после правил для приложений. Посмотрите правила, например, для Internet Explorer или svchost.exe. Вы найдете среди них правила, разрешающие этим программам делать DNS-запросы. Эти правила срабатывают до созданных вами. Можно конечно перебрать все сетевые приложения (браузеры, аськи, качалки, обязательно - svchost и прочие) и снять галочки с правил для DNS'а. Только не забудьте выключить опцию автосоздания и обновления правил для известных приложений. Иначе все ваши настройки рано или поздно собъются. Также можно сделать низкоуровневые правила с высоким приоритетом, запрещающие исходящие UDP и TCP на 53-й порт. Но я все же советую освоиться с более новыми версиями - четвертый Аутпост вам больше не нужен.
Теперь, как зайти на сайт сокс-сервиса.
Способ раз:
Убрать галочки с правил блокировки DNS. Получить соксы. Поставить галочки обратно.
Способ два:
Кому лень постоянно лезть так глубоко в настройки, сохранить два варианта конфигурации: с поставленными галочками и снятыми галочками. Через Настройки -> Общие -> Конфигурация быстро грузить нужный конфиг.
Способ три:
Найти в Интернете сайт, определяющий IP сайтов по их доменному имени. Ввести адрес вашего сервиса (MySocksService.com) и узнать на каком IP он находится (например: 123.123.123.123). После этого попробовать зайти на сайт по IP: http://123.123.123.123:80 или https://123.123.123.123:443. Если получилось - отлично. Добавляем в закладки. Линки на сайтах часто указываются относительные, при клике по ссылкам перебрасывать на URL с доменным именем вас не должно.
Способ четыре, самый удобный:
Надеюсь, вы используете виртуальную машину? Если нет - вам прямая дорога читать стати, как это делается. Фаерволл должен стоять и в хостовой, и в гостевой системе. В гостевой настраиваем блокировку DNS, в хостовой - нет. Соксы получаем из хостовой системы. Работаем - из гостевой.
Способ пять, тоже ничего:
Можно разрешить делать DNS-запросы только через VPN. В этом случае DNS вашего провайдера нигде не всплывет, но DNS ВПН'а может попалиться. Зато после подключения к ВПН сайты будут открываться и без соксов. Сначала нужно узнать IP DNS-сервера вашего VPN. Для этого подключаемся к VPN'у, запускаем программу cmd и в командной строке вводим ipconfig /all. Будет выведен список всех сетевых интерфейсов с их настройками. Ищем интерфейс VPN-подключения. В случае с OpenVPN это будет что-то типа Подключение к локальной сети #, где # - цифра. И смотрим какой DNS-сервер там указан. После этого создаем еще одно глобальное правило: Где протокол UDP и направление Исходящее и удаленный адрес (сюда ставим IP DNS'а VPN'а) и удаленный порт DNS, разрешать. Это правило ставим в самый верх списка. Теперь DNS будет работать только через VPN. Если DNS-сервер VPN'а поменяется, правило придется поправить.
JAVA, Flash и прочие пакости
Помимо прямых путей палива DNS существуют еще пути кривые. Ведут они через Java и Flash плагины браузера. Через них злые админы вообще могут узнать о нас много такого, чего им знать не полагается. Самое простое и эффективное решение - отключение Java и Flash. Оно не подходит только когда нужный сайт без этих плагинов не работает.
Утечка данных сводится в основном к двум вариантам. Отправка запроса в обход прокси (это лечится использованием Proxifier'а). И анализ настроек системы. Во втором случае помогает использование виртуальной машины, сеть которой работает в режиме NAT. Если DNS и попалится, то это будет внутренний IP хостовой машины: что-нибудь типа 192.168.0.1 - как будто инет вы получаете через локальную сетку.
Альтернативная блокировка DNS
Существует другой способ блокировки DNS-запросов. Простой, но на мой взгляд неудобный. Сводится он к указанию несуществующего DNS-сервера. Обычно при подключении IP адрес DNS-сервера вашего провайдера определяется автоматически. Но можно вручную задать какой угодно IP.
Открываем меню сетевых подключений (в Win XP: Панель управления -> Сетевые подключения). Через контекстное меню открываем свойства того подключения, через которое выходим в Интернет. Выбираем вкладку "Сеть" или "Общие" - в зависимости от типа подключения. В списке компонентов выделяем Протокол Интернета TCP/IP, жмем "Свойства". Вместо "Получить адрес DNS-сервера автоматически" выбираем "Использовать следующие адреса DNS-серверов" и прописываем IP 127.0.1.3 и 127.0.1.4.
Разумеется, на этих IP никаких DNS-серверов нет, поэтому все DNS-запросы будут уходить вникуда.
Если хотите, чтобы блокировался и DNS ВПНа, то сделайте то же самое в настройках VPN подключения.
А можно для достоверности указать в качестве DNS-сервера VPN'а какие-нибудь публичные DNS-серверы. При проверке через Flash или Java это будет выглядеть менее подозрительно, чем loopback-адрес (127.*.*.*).
Простота способа заключается в том, что не нужно разбираться с настройками всяких там Аутпостов. Серьезные недостатки: каждый раз нужно перебивать IP и переподключаться. Никаких оповещений о блокировке DNS-запроса не будет. Целенаправленные DNS-запросы к конкретным серверам блокироваться также не будут.
Вот и все. Надеюсь, мои советы кому-то помогут.
При копировании статьи или ее фрагментов указание копирайтов обязательно: © Boris The Blade.
Новогодний Бонус
В качестве бонуса подкину идею о том, что при помощи настроек фаервола можно предотвратить выход в сеть без соксов. Например, если вы забыли включить Проксифаер, он вылетел или какая-то хитроумная программа пытается выйти в сеть "в обход" него. Делается это через правила для приложений. Достаточно всем приложениям, которыми вы пользуетесь, разрешить исходящие TCP подключения только к вашему компьютеру. Доступ во внешнюю сеть оставить только Proxifier'у. И перевести Аутпост в режим блокировки.
P.P.S. Если будут проблемы с настройкой, пишите сюда. Постараюсь помочь... пока трезвый. И не забывайте заглядывать вЖурнал событий -> Брандмауэр. Когда что-то не работает, там обычно появляется много интересных записей.
P.P.P.S. Ну если еще у кого-то останутся вопросы про настройку DNS, то я уже просто не знаю...
Приложение
Провериться на предмет палива DNS можно здесь (иногда нужно несколько раз обновить страницу):
http://whoer.net
http://private.dnsstuff.com/tools/aboutyou.ch
http://www.servicevpn.net/who.html
Обратите внимание на лог Proxifier'a, когда будете заходить на эти страницы. Обращение к доменам 4-5 уровней будет очень заметно:
[/HIDE]P.P.P.P.S. Хорошо подумав, решил все же не тратить время на выкладывание статьи на других форумах, т.к. на них 90% одних и тех же людей. Все, кому было надо, уже прочитал, а мартышкин труд меня не привлекает.
Раз уж прозвучала такая заявка на качество, начну с того, что из себя представляет DNS и нахрена он нужен. А так как статья расчитана на новичков, буду объяснять совсем на пальцах.
Теория DNS
Domain Name System — система доменных имён. Если совсем коротко и по существу - позволяет определить IP адрес компьютера в сети по его доменному имени.
Допустим, среднестатистический кробер Вася, учащийся в 8-м классе, узнал про такую хорошую и совершенно необходимую вещь, как VPN. "Кру-у-ута-а-а-а...", - сказал себе Вася и, прервав просмотр накарженной порнухи, полез на сайт самого надежного и "пальцастого" VPN-сервиса. Ввел в адресной строке браузера:
[HIDE=15]vpn.mvd.ru
И нажал "Enter". Что произошло? Нет, то что Вася крупно лоханулся к нашему делу отношения не имеет. Нас интересует другое. С одной стороны, понятно что этот сайт размещен на каком-то сервере (компьютере) в Интернете. С другой - каждому известно, что компьютеры в Интернете находят друг друга по IP адресам. То есть по загадочным сериям цифр с точками вроде "95.173.128.124". Спрашивается: какого хрена наш бедный Вася должен запоминать IP каждого сайта? Ведь уже через месяц такой тренировки мозга он поумнеет и перестанет веселить достопочтенную публику своим фееричным идиотизмом. Чтобы этого не случилось, и была придумана DNS.
Теперь разберемся в том, "как оно работает". Понять причину палива после этого будет очень просто.
Если совсем упрощенно, в Интернете есть DNS-сервера. Они хранят записи о том какой IP какому доменному имени соответствует. Например:
Code:
bing.com - 65.55.175.254
ip-ping.ru - 62.152.63.130
mail.ru - 94.100.191.204
mvd.ru - 95.173.128.124
rambler.ru - 81.19.70.3
yandex.ru - 93.158.134.11
nslookup.su - 62.152.63.130Все знают, что сайтов в Интернете стало дофига. И почти у каждого сайта свой домен. Понятно, что помнить адреса всех сайтов одному DNS-серверу ну совершенно не в жилу. Поэтому каждый отдельно взятый сервер отвечает только за свой сегмент сети.
Когда компьютеру нужно узнать какому IP адресу соответствует доменное имя mail.ru, он "спрашивает" это у своего DNS-сервера. То есть делает DNS-запрос. Для начала запомните, что DNS-запросы бывают рекурсивные и нерекурсивные. В чем разница, покажу на примере.
Итак, между компьютером кардера Васи (ККВ) и DNS-сервером Васиного Интернет-провайдера (DNS-прова) происходит следующий диалог:
Теперь рассмотрим другой вариант.
В предыдущих вариантах были примеры чисто рекурсивных и чисто нерекурсивных запросов. Но на практике обычно эти варианты комбинируются: компьютер пользователя делает рекурсивный запрос к DNS-серверу своего провайдера, а тот для него начинает "обзванивать инстанции".
На другой день Вася рассказывает своему однокласснику кардеру Пете, какую классную штуку он нашел. И тот (а я чо - лох?! я тоже хочу дрочить через VPN, так оно безопаснее!) лезет на наш многострадальный сайт "лучшего VPN-сервиса для русских кардеров". Т.к. мегакардеры живут рядом, провайдер у них один (и DNS-прова один и тот же).
* Вариант IV - кэширование DNS *
ККП => DNS'у прова:- Привет. Пете нужен сайт vpn.mvd.ru, какой у него IP?
- Как же, как же. Вчера у меня этот домен уже спрашивали, IP вряд ли поменялся: 95.173.128.124.
Как видим, DNS-сервер провайдера обычно запоминает IP адреса доменов на некоторое время. Петя засветился только на DNS'е провайдера. А остальные DNS-сервера про то, что Петя интересовался этим сайтом, не в курсе.
Паливо ДНСа
В механизме работы DNS мы немного разобрались. Конечно, на деле все горазно сложнее, но для нас это не важно. Для нас гораздо важнее, как этот механизм используется, чтобы нас попалить. Так что же нужно злым админам с mvd.ru, чтобы схватить Васю и Петю за жопу?
а) Свой DNS-сервер, который они контролируют. Он будет фиксировать DNS-запросы и стучать админам;
б) Избежать DNS-кэширования, чтобы все запросы проходили на их DNS-сервер;
в) Как-то отличать DNS-запросы Васи от запросов Пети (и еще тысяч других).С пунктом а) все ясно - ставят DNS на своем серваке и регистрируют его в более старших DNS-серверах (зоны .ru или корневых - не важно).
С пунктами б) и в) тоже все просто. Нужно как-то заставить компьютеры посетителей делать уникальные DNS-запросы на сервер mvd.ru. Они не будут повторяться, поэтому их кэширование не имеет значения. И у каждого посетителя они будут разные, поэтому проверить какой запрос сделан каким пользователем тоже очень просто. Нужно только запомнить, какой домен подсовывался Васе, а какой - Пете.
Как же заставить Васю сделать запрос ya-vasya.mvd.ru, а Петю ya-petya.mvd.ru? Ведь они оба будут вводить в браузерvpn.mvd.ru. Элементарно. Достаточно подделать ссылку на любую картинку или CSS-файл (или любой другой файл), которые будут грузиться вместе со страничкой. В HTML-коде страницы, которую покажут Васе, будет строчка:
Code:
<link href="http://ya-vasya.mvd.ru/styles22.css" rel="stylesheet" type="text/css">
А на странице, которую покажут Пете:
Code:
<link href="http://ya-petya.mvd.ru/styles22.css" rel="stylesheet" type="text/css">
И браузер послушно загрузит эти файлы, чтобы отобразить страницы в том виде, в каком они задуманы веб-мастерами. Надеюсь, уточнять что при этом компьютер Васи сделает DNS-запрос ya-vasya.mvd.ru, а Пети - ya-petya.mvd.ru, не нужно. Ну и отмечу, что на деле будут не фразы типа "ya-vasya", "ya-petya", а какой-нибудь буквенно-числовой идентификатор посетителя (что-нибудь вроде f8117b00ca8d11f54.mvd.ru).Если DNS-запрос к провайдеру будет рекурсивным, то на DNS-mvd.ru полезет DNS-прова, и спалят его. Если нерекурсивным, то компьютер пользователя будет сам спрашивать у DNS-mvd.ru IP домена и попалится сам. Все зависит от настройки DNS-сервера провайдера. При этом не важно, используют ли Вася и Петя прокси или нет. В первом случае запрос будет делать провайдер, а у него никаких прокси нет и в помине. Во втором - DNS-запросы обычно идут в обход прокси. Глобальные проксификаторы операционной системы (Proxifier, WideCap) в обычном режиме тоже не помогут: они перехватывают TCP сессии, а DNS-запросы делаются по UDP протоколу.
Паливо VPN'а
Почему при использовании VPN обычно палится DNS VPN'а, а не провайдера? Если не вдаваться в детали, то потому что VPN-соединение считается своего рода "подключением к Интернету по умолчанию". Если ВПН настроен нормально, то его шлюз является основным, внешний трафик идет на него и определение IP сайтов происходит через DNS-сервер VPN-сервиса. Это уже лучше, но еще не изумительно.
Прячем свой DNS за соксом
Гораздо лучше, если вместо DNS VPN'а будет палиться ДНС натянутого поверх него сокса. Почему? Потому что соксы нам для того и нужны, чтобы их палить
Соксы изначально были задуманы для того, чтобы обеспечить взаимодействие сетей, связь между которыми затруднительна. Сокс - своего рода промежуточный сервер, у которого есть доступ к обеим сетям, которые нужно связать. Поэтому в протоколе SOCKS предусмотрели возможность разрешения доменных имен. Для справки: разрешить доменное имя - значит получить его IP адрес.
Значит компьютер Васи сперва через сокс делает DNS-запрос. Определяет IP хоста vpn.mvd.ru. А потом через сокс же работает с этим IP. Так? Нет, не так. Васин компьютер просто кладет на то, какой IP у этого сайта. Он требует от сокса: "Обеспечь мне связь с хостом vpn.mvd.ru!". Остальное - забота сокса. Он сам будет делать DNS-запрос, чтобы определить IP. Логично спросить: а нахрена я рассказываю про эти тонкости? Да просто чтобы стало понятно: компьютер с правильно настроенным соксификатором при работе через сокс DNS-запросов не делает! Это ему просто не нужно. Зато это очень нужно злым админам нехороших сайтов, чтобы нас попалить.
Настраиваем соксификатор
Теперь про то, как настроить соксификатор. Расскажу об этом на примере программы Proxifier - она наиболее удобная из всех, какими я пользовался. В ней предусмотрено два режима работы с DNS: локальный и удаленный. В локальном режиме компьютер сперва сам определяет IP при помощи DNS-сервера своего провайдера. А уже потом подключается к этому IP через сокс. В этом случае палится либо IP компа, либо DNS провайдера, либо DNS ВПНа. А при удаленном разрешении имен все происходит, как описано выше. Соксу передается доменное имя хоста, к которому нужно подключиться. И он сам пытается определить его IP через свой DNS. Именно такой режим нам и нужен.
Открываем окно Proxifier'а, идем в меню Options -> Name Resolution. Видим галочку Choose the mode automatically и быстренько ее снимаем. Выбирать режим автоматически нам ни к чему - выбор будет явно не в нашу пользу. Далее видим переключатель Locally / Try Locally then Remotely / Remotely. Соответственно: Локально / Попробовать сперва локально, если не получилось - удаленно / Удаленно. Нас интересует последний вариант. Ставим переключатель в положение Remotelyи радуемся жизни.
Вот вроде бы и все, проблема решена. И тут у некоторых возникнет вопрос: а нахрена читать дальше? Для них напомню, что Вася тоже радуется жизни... хотя и юзает ментовский ВПН. Камрады, не будьте васями, читайте дальше!
Отсыпьте-ка мне сверхдлинных запросов...
Теперь, когда малолетние онанисты отсеялись, расскажу про парочку ньюансов. Ведь нас все еще могут ухватить за задницу Сами-Знаете-Кто. Догадываюсь, что такой массаж уважаемой публике ни к чему.
Во-первых, операционная система не в курсе гнусных попыток Proxifier'а послать все на... сокс. Процесс перехвата DNS-запроса системы и отправки вместо этого на сокс доменного имени довольно гемморойный. Во-вторых, из-за кривизны различных настроек Проксифаер может не перехватить попытки какой-нибудь программы выйти в сеть. В-третьих, программа может иметь свои средства разрешения имен и нагло игнорировать стандартные средства системы. Или пользователь может просто забыть включить Проксифаер или добавить в него сокс. Короче говоря, несмотря на правильные настройки Proxifier'а, какой-нибудь шальной DNS-запрос все же может проскочить. Как же с этим бороться?
И тут самое время вспомнить, что многие кроберы с упорством, достойным лучшего применения, атакуют форумы с вопросами: "А где взять четвертый Outpost?..". Более молодые с не меньшим упорством переспрашивают: "А зачем именно четвертый?". Вопрос вполне закономерный, так как эта версия уже давным давно устарела и не обеспечивает наилучшей защиты. На что следует поучительный ответ: "В нем есть блокировка сверхдлинных запросов".
Напомню, что обычный DNS-запрос (вроде "скажи мне IP хоста porno.ru") ничем не опасен. Таких запросов сервер ежедневно получает миллионы. И обслуживают такие запросы не DNS-сервера отдельных сайтов, которые можно контролировать, а "главнюки" зоны .ru. Чтобы отличить запрос онаниста Васи от запроса онаниста Пети, нужно чтобы они:
а) попали на шпионящий DNS-сервер
б) отличались друг от другаТо есть имели вид вроде: fb81a4c57d1a781ff.Domain-Zone-of-Our-Spying-DNS-Server.porno.ru. Вот тогда пользователя с ID fb81a4c57d1a781ff можно хватать за яйца. Именно такие запросы называются сверхдлинными. И именно их блокирует Outpost 4.0. НО! Если мне не изменяет память, сверхдлинным считается запрос на разрешение имени домена четвертого уровня и выше. То есть доменное имя css.server.ru не является сверхдлинным, а f7c1b14.css.server.ru - уже сверхдлинное. Так что спешу порадовать любителей четвертого Аутпоста: запрос типа fb81a4c57d1a781ff.google.com заблокирован не будет. А ведь у такого гиганта как Гугл наверняка есть свои низкоуровневые DNS-сервера. И вполне могут шпионить, если настроены для этого. Так что условия а) и б) выполняются. Вы рады? Я тоже рад за вас!
Почему же старина Аутпост кинул нам такую подлянку? Потому что эта блокировка задумывалась как защита от пересылки данных трояном при помощи DNS-запроса. (login-vasya-password-zhopa.hackers.dns.server.com). В более поздних версиях разработчики признали такую защиту неэффективной и отказались от блокировки сверхдлинных запросов. Прикрывать нас от злых админов в погонах разрабы никогда не собирались.
Так что же делать? Для начала в клиническом ужасе кричим "Ааааааааа!.." и начинаем рвать на жопе волосы. А потом вспоминаем, что "компьютер с правильно настроенным соксификатором при работе через сокс DNS-запросов не делает!". И читаем дальше.
Мочим ДНСов
Раз DNS-запросы не нужны, но могут быть опасны, логичнее всего отказаться от них. То есть заблокировать их все. И сверхдлинные, и сверхкороткие, и даже сверхсредние... И в этом нам поможет наш старый добрый Аутпост, который, надеюсь, вы все используете. Ибо сказано было: "И да настанет Судный День у каждой машины, и да пребудет великая боль с ее хозяином в час отречения от истиннаго владыки - Великого Аутпоста"(© "Откровение от Порочного Бориса", писание первое, глава первая - "Начало").
Что из себя представляет DNS-запрос по своей сути, мы уже разобрались. Технически же он выглядит как исходящий трафик по UDP протоколу на порт DNS. Или как исходящее TCP соединение на порт DOMAIN.
Допустим, 95.31.1.83 - это IP DNS-сервера нашего провайдера. Тогда DNS-запрос для Аутпоста будет выглядеть:
Исходящий UDP на 95.31.1.83:53
Исходящий TCP на 95.31.1.83:53(DNS и DOMAIN - это названия 53-го порта для UDP и TCP протоколов соответственно). Их-то нам и надо укокошить. Беда в том, что наш Аутпост про такую сверхзадачу не в курсе. Пока не в курсе
Все, что нужно - сделать правила блокировки такого трафика. А делать такие правила удобнее в новых версиях, так как они в этом смысле более гибкие.Объяснять буду самый простой способ. Он не самый удобный, но его проще и быстрее всего объяснить. Кто хочет лучшего - разберется.
Открываем окно Аутпоста (например, 2009). Настройки -> Брандмауэр -> Сетевые правила -> Системные правила. Должно появится окошко со вкладкой Глобальные правила. В других версиях интерфейс может быть другой, но окно настройки глобальных правил в нем есть. Ищите.
Видим список глобальных правил, разделенных на две категории: Применяются до правил для приложений, Применяются после правил для приложений. Вторая категория нам не интересна: правила какого-нибудь приложения могут разрешать для него DNS-запросы. И наткнувшись на это правило Аутпост разрешит этой программе сделать DNS-запрос. А нам нужно, чтобы Аутпост сперва наткнулся на наше запрещающее правило. Так уж он устроен: нашел первое подходящее правило - применяет, дальше не смотрит.
Тыкаем кнопку "Добавить".
Первое окошко - событие, в нем выбираем "Где направление" и "Где удаленный порт".
В третьем окошке "Расшифровка правила" появится: "Где протокол TCP и направление Не определено и удаленный порт Не определен, разрешать". Кликаем по TCP, выбираем "UDP". Если в первом окошке какие-то галочки соскочили, ставим по новой.
Аналогично в направлении указываем "Исходящее".
Потом тыкаем по Не определен в пункте "Удаленный порт". В появившемся окне ищем порт DNS (53) и дважды кликаем. Жмем "Ок".
Теперь щелкаем по Разрешать, чтобы оно сменилось на "Блокировать".
Так выглядит правило "Блокировать исходящие UDP на 53-й порт". Или, говоря по-человечески "Блокировать исходящие DNS-запросы"
Еще одна маленькая, но приятная деталь. В окошке 2 "Параметры правила" поставьте галочку Оповещать. Зачем? Чтобы вы не материли бедного Бориса каждый раз, когда забудете включить Proxifier, добавить в него сокс или сокс умрет и у вас тупо не будут открываться сайты. Каждый раз при срабатывании правила внизу будет появляться всплывающее окошечко с сообщением. И будет понятно, что Интернет не работает из-за блокировки DNS-запросов. Окошки эти появляются обычно в самый неподходящий момент, когда вы что-то куда-то вводите. Так что материть меня и Аутпоста вы все равно будете, но уже за сбитый с поля ввода фокус. Но мне оно так приятнее...
Верно настроенное правило выглядит так:
Жмем Ок. В окне с глобальными правилами выделяем строчку с нашим правилом. И топим кнопку "Вверх", пока оно не поднимется на самую верхушку списка. Для тех, кто в танке: галочка напротив правила должна стоять.
Точно так же делаем второе правило, но в нем вместо протокола UDP оставляем TCP. Все остальное так же, только 53-й порт будет называться "DOMAIN". Ставим его вторым в списке.
Все, теперь все попытки сделать DNS-запрос будут пресечены. За исключением запроса на нестандартный порт. Но система делать такого не будет, только какая-нибудь хитроумная программа, а это уже тема совсем другого разговора.
Не ругайте Борьку!
Теперь поговорим про тех, кто все настроил, и у кого ничего не получилось. То есть про тех, кто пытался сделать все как я сказал, но в четвертом Аутпосте, поленившись поставить новую версию. А также про самых внимательных, которые мерзким голосом заметят: "хорошо, при работе через сокс DNS-запросы не нужны... но где взять сокс, ведь для этого сперва нужно зайти на сайт сокс-сервиса?!"
На это отвечу: "Негоже сетовать на судьбу и Господа, коли очаг страстей и рукоблудия созидает Человек в своем Незнании истинных Законов, дарованных нам Великим Аутпостом!"(© "Откровение от Порочного Бориса", писание первое, глава первая - "Начало"). (Вася, Петя, привет!)
В четвертом Аутпосте нет разделения глобальных правил на применяющиеся до и после правил для приложений. Его глобальные правила применяются всегда после правил для приложений. Посмотрите правила, например, для Internet Explorer или svchost.exe. Вы найдете среди них правила, разрешающие этим программам делать DNS-запросы. Эти правила срабатывают до созданных вами. Можно конечно перебрать все сетевые приложения (браузеры, аськи, качалки, обязательно - svchost и прочие) и снять галочки с правил для DNS'а. Только не забудьте выключить опцию автосоздания и обновления правил для известных приложений. Иначе все ваши настройки рано или поздно собъются. Также можно сделать низкоуровневые правила с высоким приоритетом, запрещающие исходящие UDP и TCP на 53-й порт. Но я все же советую освоиться с более новыми версиями - четвертый Аутпост вам больше не нужен.
Теперь, как зайти на сайт сокс-сервиса.
Способ раз:
Убрать галочки с правил блокировки DNS. Получить соксы. Поставить галочки обратно.
Способ два:
Кому лень постоянно лезть так глубоко в настройки, сохранить два варианта конфигурации: с поставленными галочками и снятыми галочками. Через Настройки -> Общие -> Конфигурация быстро грузить нужный конфиг.
Способ три:
Найти в Интернете сайт, определяющий IP сайтов по их доменному имени. Ввести адрес вашего сервиса (MySocksService.com) и узнать на каком IP он находится (например: 123.123.123.123). После этого попробовать зайти на сайт по IP: http://123.123.123.123:80 или https://123.123.123.123:443. Если получилось - отлично. Добавляем в закладки. Линки на сайтах часто указываются относительные, при клике по ссылкам перебрасывать на URL с доменным именем вас не должно.
Способ четыре, самый удобный:
Надеюсь, вы используете виртуальную машину? Если нет - вам прямая дорога читать стати, как это делается. Фаерволл должен стоять и в хостовой, и в гостевой системе. В гостевой настраиваем блокировку DNS, в хостовой - нет. Соксы получаем из хостовой системы. Работаем - из гостевой.
Способ пять, тоже ничего:
Можно разрешить делать DNS-запросы только через VPN. В этом случае DNS вашего провайдера нигде не всплывет, но DNS ВПН'а может попалиться. Зато после подключения к ВПН сайты будут открываться и без соксов. Сначала нужно узнать IP DNS-сервера вашего VPN. Для этого подключаемся к VPN'у, запускаем программу cmd и в командной строке вводим ipconfig /all. Будет выведен список всех сетевых интерфейсов с их настройками. Ищем интерфейс VPN-подключения. В случае с OpenVPN это будет что-то типа Подключение к локальной сети #, где # - цифра. И смотрим какой DNS-сервер там указан. После этого создаем еще одно глобальное правило: Где протокол UDP и направление Исходящее и удаленный адрес (сюда ставим IP DNS'а VPN'а) и удаленный порт DNS, разрешать. Это правило ставим в самый верх списка. Теперь DNS будет работать только через VPN. Если DNS-сервер VPN'а поменяется, правило придется поправить.
JAVA, Flash и прочие пакости
Помимо прямых путей палива DNS существуют еще пути кривые. Ведут они через Java и Flash плагины браузера. Через них злые админы вообще могут узнать о нас много такого, чего им знать не полагается. Самое простое и эффективное решение - отключение Java и Flash. Оно не подходит только когда нужный сайт без этих плагинов не работает.
Утечка данных сводится в основном к двум вариантам. Отправка запроса в обход прокси (это лечится использованием Proxifier'а). И анализ настроек системы. Во втором случае помогает использование виртуальной машины, сеть которой работает в режиме NAT. Если DNS и попалится, то это будет внутренний IP хостовой машины: что-нибудь типа 192.168.0.1 - как будто инет вы получаете через локальную сетку.
Альтернативная блокировка DNS
Существует другой способ блокировки DNS-запросов. Простой, но на мой взгляд неудобный. Сводится он к указанию несуществующего DNS-сервера. Обычно при подключении IP адрес DNS-сервера вашего провайдера определяется автоматически. Но можно вручную задать какой угодно IP.
Открываем меню сетевых подключений (в Win XP: Панель управления -> Сетевые подключения). Через контекстное меню открываем свойства того подключения, через которое выходим в Интернет. Выбираем вкладку "Сеть" или "Общие" - в зависимости от типа подключения. В списке компонентов выделяем Протокол Интернета TCP/IP, жмем "Свойства". Вместо "Получить адрес DNS-сервера автоматически" выбираем "Использовать следующие адреса DNS-серверов" и прописываем IP 127.0.1.3 и 127.0.1.4.
Разумеется, на этих IP никаких DNS-серверов нет, поэтому все DNS-запросы будут уходить вникуда.
Если хотите, чтобы блокировался и DNS ВПНа, то сделайте то же самое в настройках VPN подключения.
А можно для достоверности указать в качестве DNS-сервера VPN'а какие-нибудь публичные DNS-серверы. При проверке через Flash или Java это будет выглядеть менее подозрительно, чем loopback-адрес (127.*.*.*).
Простота способа заключается в том, что не нужно разбираться с настройками всяких там Аутпостов. Серьезные недостатки: каждый раз нужно перебивать IP и переподключаться. Никаких оповещений о блокировке DNS-запроса не будет. Целенаправленные DNS-запросы к конкретным серверам блокироваться также не будут.
Вот и все. Надеюсь, мои советы кому-то помогут.
При копировании статьи или ее фрагментов указание копирайтов обязательно: © Boris The Blade.
Новогодний Бонус
В качестве бонуса подкину идею о том, что при помощи настроек фаервола можно предотвратить выход в сеть без соксов. Например, если вы забыли включить Проксифаер, он вылетел или какая-то хитроумная программа пытается выйти в сеть "в обход" него. Делается это через правила для приложений. Достаточно всем приложениям, которыми вы пользуетесь, разрешить исходящие TCP подключения только к вашему компьютеру. Доступ во внешнюю сеть оставить только Proxifier'у. И перевести Аутпост в режим блокировки.
P.P.S. Если будут проблемы с настройкой, пишите сюда. Постараюсь помочь... пока трезвый. И не забывайте заглядывать вЖурнал событий -> Брандмауэр. Когда что-то не работает, там обычно появляется много интересных записей.
P.P.P.S. Ну если еще у кого-то останутся вопросы про настройку DNS, то я уже просто не знаю...
Приложение
Провериться на предмет палива DNS можно здесь (иногда нужно несколько раз обновить страницу):
http://whoer.net
http://private.dnsstuff.com/tools/aboutyou.ch
http://www.servicevpn.net/who.html
Обратите внимание на лог Proxifier'a, когда будете заходить на эти страницы. Обращение к доменам 4-5 уровней будет очень заметно:
Code:
[HH:MM] Error : the proxy server X.X.X.X:YYYY cannot establish connection to 2108de08-cc03-4500-bf07-517f5d33630a.css.servicevpn.net:80
[HH:MM] SomeBrowser.exe - Could not connect to 2108de08-cc03-4500-bf07-517f5d33630a.css.servicevpn.net:80 through the proxy server.
[HH:MM] SomeBrowser.exe - www.dnsstuff.com:80 open
...
[HH:MM] SomeBrowser.exe - Could not connect to ibid183880237.plumd.dnsstuff.com:80 through the proxy server.
[HH:MM] Error : the proxy server X.X.X.X:YYYY cannot establish connection to 2108de08-cc03-4500-bf07-517f5d33630a.css.servicevpn.net:80
[HH:MM] SomeBrowser.exe - Could not connect to 2108de08-cc03-4500-bf07-517f5d33630a.css.servicevpn.net:80 through the proxy server.
[HH:MM] SomeBrowser.exe - www.dnsstuff.com:80 close, 482 bytes sent, 46450 bytes (45.3 KB) received
[HH:MM] SomeBrowser.exe - meineipadresse.de:80 close, 416 bytes sent, 1660 bytes (1.62 KB) received