Техническое: VPN и использование DNS
Спрашивают в комментариях к записке об использовании открытых и “чужих” сетей – зачем нужен собственный резолвер DNS, налаженный внутри VPN?
Давайте сперва вспомним типичный сценарий использования DNS. Для того, чтобы получить адрес узла, соответствующего данному имени, нужно опросить несколько серверов DNS. Обычно, этот опрос берёт на себя некий резолвер (специальная программа), принадлежащий провайдеру услуг доступа в Интернет и выполняющий извлечение адресов по запросам клиентских компьютеров.
Понятно, что в случае с собственным VPN-соединением, запущенным через “чужую” сеть, определять адреса серверов может всё тот же провайдерский резолвер. В конце концов, через VPN ходит TCP/IP, а не символьные имена доменов. После того, как резолвер определил IP-адрес сервера, соединение будет устанавливаться уже через VPN.
Но, как вы понимаете, паранойя встречается разных типов и масштабов, а резолвер провайдера как раз и используется для того, чтобы осуществлять подмену адресов страниц. Ведь именно при помощи подстановки “кривого” адреса в ответ на запрос о любом домене происходит переадресация браузера на замечательные страницы с предложением приобрести ту или иную услугу, с напоминанием о том, что на счёте мало денег, и так далее, и тому подобное. “Чужой” резолвер ставит крест на всех полезностях VPN, если, конечно, вы планируете использовать DNS. (Кроме того, если вы настроили локальную маршрутизацию таким образом, что весь трафик ходит через VPN, может возникнуть проблема: резолвер владельца сети не станет обслуживать запросы, поступающие с вашего компьютера, потому что они будут приходить извне – со стороны шлюза VPN.)
Другое решение – держать рекурсивный резолвер локально, на своём ноутбуке. Я не уверен, может ли это делать Windows (наверное, может), но с юниксоподобными системами проблем нет, достаточно поднять локальный BIND. Трафик резолвера нужно завернуть в VPN, это обеспечит секретность. (Тут есть подводный камень: использование NAT, – а трафик из VPN во внешний мир может выходить именно через NAT, – грозит тем, что испортится один из защитных механизмов DNS, который называется “рандомизация портов UPD на источнике запроса”; но это другая история.) А главный недостаток один: нужно на каждом клиенте VPN держать свой рекурсивный резолвер. Неудобно. Поэтому куда более логично разместить собственный резловер на сервере, обеспечивающем VPN. Всё равно этот сервер работает постоянно.
А кроме того, редкий провайдерский резолвер поддерживает DNSSEC. Я таких вообще не видел.
(И, хорошо, можно использовать открытые сервисы, наподобие Google public DNS, но это всё ж не то решение, которое сравнится с собственным резолвером. При этом гугловский сервис быстрее. В моём случае – заметно быстрее.)
Адрес записки: https://dxdt.ru/2012/03/07/4647/
Похожие записки:
- Реплика: перенос доменных имён и GoDaddy
- Детерминированный вариант ECDSA
- Утечка DNS-запросов в ExpressVPN
- ИИ для принятия решений
- Обобщение ИИ и "кнопки на пульте"
- Техническое: имена в TLS и Nginx
- Техническое: один практический пример ошибочных настроек DNS
- Браузер Chrome 122 и Kyber768
- "Блокирующие" источники случайности в операционных системах
- Физико-химические структуры от AI Google
- Наложенные сети Google и браузеры в будущем
Комментарии читателей блога: 6
1 <t> // 7th March 2012, 22:54 // Читатель Alatar написал:
Раз заметка техническая, можно чуть побольше техники? Я не особо силён в системном администрировании, по-этому меня мучает таки вопрос – откуда берёт данные этот наш ДНС? Точнее, к кому он за этими данными обращается? Непосредственно к корневым серверам, а потом куда они пошлют? Просто мой скудный опыт настройки ДНС на локалхосте напоминает мне, что в конфиге BIND обычно указываются адреса форвардеров. Как я понял, в Вашем варианте форвардеры не используются, иначе никакого смысла нет.
Да, кстати, как думаете, насколько можно считать доверенным гугловый 8.8.8.8?
2 <t> // 7th March 2012, 23:20 // Александр Венедюхин:
> откуда берёт данные этот наш ДНС? Точнее, к кому он за этими данными обращается?
Сперва к корневым серверам, потом дальше – Вы всё верно написали. Для dxdt.ru – цепочка будет такая: 1) корневой сервер; 2) сервер домена .ru; 3) сервер домена dxdt.ru.
> указываются адреса форвардеров.
Это как раз и есть ситуация, когда преобразование (обход серверов имён) выполняют другие резолверы. Но BIND сам может проделать всю работу, то есть, пройти по всей “рекурсивной цепочке”.
> в Вашем варианте форвардеры не используются
Да, верно. Это, кстати, конфигурация BIND по умолчанию.
> насколько можно считать доверенным гугловый 8.8.8.8?
Непростой вопрос. С одной стороны, _сам_ гугловый сервис оказывается вне пределов сети, где может происходить перехват, вне досягаемости владельца этой сети. С другой стороны – адреса-то заранее известны, а аутентифкации там нет. Поэтому владельцу сети, через которую вы подключились к Интернету, ничего особенно не мешает подменить весь трафик к гугловским DNS и от них, если возникнет такое желание.
Это, кстати, ещё одна причина, по которой нужно держать DNS за VPN.
3 <t> // 8th March 2012, 12:14 // Читатель Alatar написал:
Ага, спасибо
>>С другой стороны – адреса-то заранее известны, а аутентифкации там нет. Поэтому владельцу сети, через которую вы подключились к Интернету, ничего особенно не мешает подменить весь трафик к гугловским DNS и от них, если возникнет такое желание.
Дык трафик-то к нему через VPN пойдёт, так что неизвестному провайдеру он даже виден не будет. Вопрос скорее с точки зрения порядочности гугла. Подменять ответы они вряд ли будут, но они ведь могут использовать информацию о DNS запросах для формирования моего портрета. С учётом того, какое у них количество потенциальных датчиков информации, как-то не по себе становится.
4 <t> // 8th March 2012, 15:39 // Читатель jno написал:
Заметим, что можно использовать(“абъюзить”) и сервисы, вроде, rejector.ru
Да и у регистраторов встречаются открытые DNS-сервисы…
5 <t> // 8th March 2012, 19:02 // Читатель зашел в гости написал:
“Это, кстати, ещё одна причина, по которой нужно держать DNS за VPN.”
я, если честно, все равно не до конца понимаю, как вам поможет VPN. Вы зашифруете свой траффик между вашим сервером и домашним компьютером/ноутбуком, хорошо. Но “сервер” – это всего лишь процесс, который работает на машине, которую вы не контролируете, а сама машина подключена к сети, конфигурацию которой вы не знаете. Если владелец сети сам готов заниматься мошенничеством, или недостаточно компетентен, чтобы обезопасить сеть и машину с вашим процессом, то не будут ли ваши усилия с VPN пустой тратой сил? Что мешает владельцу перехватывать НЕ зашифрованный траффик с вашего сервера “на выходе”? Ведь этот траффик не зашифрован и может перехватываться другим процессом на самой машине, маршрутизатором и т.д.? Нет?
6 <t> // 8th March 2012, 21:55 // Александр Венедюхин:
Может, конечно. То есть, если говорить о том примере с VPN до сервера в Amazon EC2, то в амазоновских недрах, теоретически, могут и перехватить трафик, и подменить его местами (кроме https). Ну так я изначально об этом упомянул. Но тут есть существенный выигрыш в плане “управления рисками” – доверять одной более или менее надёжной сети (Amazon) лучше, чем доверять подряд всем мелким самодельным сеткам.