Не через 5-10 лет, а уже. Tesla Roadster продается малой серией (дорого очень > $100K). В следующем году будут более дешевые (~$40K) Chevy Volt (оно же Opel Ampera), Mitsubishi i MiEV.
1. Согласен, у меня переклинило originating host с local host. Возможность сделать traceroute это все равно не дает.
2. Терминирующий сервер VPN будет самым ближним и скорее всего наиболее удобным для использования в качестве DNS-сервера.
Который DNS -> Java -> System? Этот берет напрямую от системы. Интереснее те, которые пытаются отрезолвить уникальное имя: DNS -> Browser и DNS -> Java -> Resolve.
Нет, DNS Leak используют немного не так. Подробности смотрите в исходнике страницы по ссылкам в начале статьи. Обратите внимание на параметры flash_ajax_request( «dns_unique_domain»)
Java applet в browser'е никаких traceroute сделать не сможет, посколько ограничен соединением только с локальным хостом, на котором запущен броузер.
DNS Leak так же лечится если использовать в качестве DNS сервера хост на котором терминируется VPN.
Если берете авторство статьи на себе — тогда отдувайтесь, потому что бреда в ней навалом. Начните с выяснения что же такое VPN на самом деле, вы, судя по всему, этим словом называете PPTP.
Дальше следующие перлы в статье:
> VPN-сервер, в свою очередь, этот пакет расшифрует, разберется, в чем его суть (запрос на закачку какой-либо HTTP-страницы, просто передача данных и т.д.), и выполнит от своего лица (то есть засветит свой IP) соответствующее действие
VPN сервер ни в чем не разбирается, а шлет пакет по роутингу.
> VPN-сервер поместит его в GRE-пакет, зашифрует и в таком виде отправит обратно клиенту
В GRE нет шифрования, это протокол инкапсуляции.
> Поддерживает гибкие методы авторизации подлинности клиента, основанные на сертификатах;
PPTP тоже умеет авторизацию по сертификатам (EAP-TLS)
> HTTP-прокси работают они только с HTTP (есть и https-прокси)
HTTP-прокси прекрасно организуют туннели через метод CONNECT, чем пользуются, к примеру ICQ и Skype.
> Протокол SOCKS наиболее примечателен тем, что он инкапсулирует протоколы не прикладного, а транспортного уровня, т.е. TCP/IP и UDP/IP.
SOCKS на самом деле прокси сессионного уровня. А UDP/IP — оригинальное написание.
> По этой же причине все SOCKS-сервера анонимны
Кто куда ходил — все прекрасно логгируется.
> Анонимайзеры представляют собой скрипты, написанные, например, на perl, php, cgi-скрипты.
У автора опять проблемы с категоризацией, perl и php — это обычно и есть CGI-скрипты.
> весь сетевой софт на компьютере форвардится на назначенный порт (вашего локалхоста), на котором висит сервис, соединенный по SSH с сервером
А зачем весь софт форвардить на один порт? Или автор смешал ssh port forwarding с ssh tunneling?
Резюме — вся статья написана на уровне обычного скрипткиддиса, много кульных названий и сокращений, а в деталях — бред и фантазии.
Надеюсь что SCO UNIX уже все вымерли и вам не придется с ними столкнуться, потому что вас сразу же бы постигло жесткое разочарование в кроссплатформенности killall. На данной системе killall убивает ВСЕ процессы в системе, не связанные с процедурой shutdown, причем по умолчанию через SIGKILL, а не через SIGTERM.
Судя по всему, приведенные примеры настроек примерно наполовину представляет из себя летопись хождения по граблям — как говорит сам автор, «каждая строчка писана кровью».
Сначала программист, не подозревающий о Cache-Control, наступает на первые грабли и случайно отключает кеширование главной страницы. Автор предполагает, что лучшее решение это запрет Cache-Control на корню, но в результате наступает на несколько очередных грабель — во-первых, из-за отсутствия Cache-Control начинают кешироваться Cookie, а во-вторых, из-за отрезанных Expires страницы начинают плохо кешироваться в броузерах, которые в результате шлют слишком много запросов с If-Modified-Since. С первым справляемся отрезанием самих Cookie, а со вторым — кешированием ответов 304 Not Modified. Напоследок же автор пытается эмулировать Cache-Control через отрезание Last-Modified, что уже напрямую идет вразрез RFC на HTTP/1.1 и скорее всего, чревато очередными граблями.
В итоге же все это комсомольское путешествие оказывается всего-лишь следствием одного из возможных решений специфической проблемы автора и совсем не обязательно разламывать управление кешированием HTTP из-за того, что какой-то программист однажды накосячил. Так что рекомендую воспринимать эту статью с хорошей долей grain of salt и думать самостоятельно о последствиях отключения чего-либо.
Если у вас контент страницы зависит от некоего user_id, то засуньте тогда значение этого user_id в fastcgi_cache_key — тогда будут кешироваться разные варианты страницы в зависимости от cache_key.
Пишут, что причина — некорректное обновление софта, а так у них якобы обычно все по процедуре и два независимых тестера все проверяют. Хотя судя по результату — где-то в процедурах у них есть приличные дыры, раз такие классических огрехи проскальзывают.
I would like to especially acknowledge Douglas Crockford's work on JSLint. This lint is itself written in Javascript and is an interesting and rather sophisticated script. Crockford's ideas about good coding practices served as a springboard for many of these lint rules.
2. Терминирующий сервер VPN будет самым ближним и скорее всего наиболее удобным для использования в качестве DNS-сервера.
DNS Leak так же лечится если использовать в качестве DNS сервера хост на котором терминируется VPN.
Дальше следующие перлы в статье:
> VPN-сервер, в свою очередь, этот пакет расшифрует, разберется, в чем его суть (запрос на закачку какой-либо HTTP-страницы, просто передача данных и т.д.), и выполнит от своего лица (то есть засветит свой IP) соответствующее действие
VPN сервер ни в чем не разбирается, а шлет пакет по роутингу.
> VPN-сервер поместит его в GRE-пакет, зашифрует и в таком виде отправит обратно клиенту
В GRE нет шифрования, это протокол инкапсуляции.
> Поддерживает гибкие методы авторизации подлинности клиента, основанные на сертификатах;
PPTP тоже умеет авторизацию по сертификатам (EAP-TLS)
> HTTP-прокси работают они только с HTTP (есть и https-прокси)
HTTP-прокси прекрасно организуют туннели через метод CONNECT, чем пользуются, к примеру ICQ и Skype.
> Протокол SOCKS наиболее примечателен тем, что он инкапсулирует протоколы не прикладного, а транспортного уровня, т.е. TCP/IP и UDP/IP.
SOCKS на самом деле прокси сессионного уровня. А UDP/IP — оригинальное написание.
> По этой же причине все SOCKS-сервера анонимны
Кто куда ходил — все прекрасно логгируется.
> Анонимайзеры представляют собой скрипты, написанные, например, на perl, php, cgi-скрипты.
У автора опять проблемы с категоризацией, perl и php — это обычно и есть CGI-скрипты.
> весь сетевой софт на компьютере форвардится на назначенный порт (вашего локалхоста), на котором висит сервис, соединенный по SSH с сервером
А зачем весь софт форвардить на один порт? Или автор смешал ssh port forwarding с ssh tunneling?
Резюме — вся статья написана на уровне обычного скрипткиддиса, много кульных названий и сокращений, а в деталях — бред и фантазии.
Сначала программист, не подозревающий о Cache-Control, наступает на первые грабли и случайно отключает кеширование главной страницы. Автор предполагает, что лучшее решение это запрет Cache-Control на корню, но в результате наступает на несколько очередных грабель — во-первых, из-за отсутствия Cache-Control начинают кешироваться Cookie, а во-вторых, из-за отрезанных Expires страницы начинают плохо кешироваться в броузерах, которые в результате шлют слишком много запросов с If-Modified-Since. С первым справляемся отрезанием самих Cookie, а со вторым — кешированием ответов 304 Not Modified. Напоследок же автор пытается эмулировать Cache-Control через отрезание Last-Modified, что уже напрямую идет вразрез RFC на HTTP/1.1 и скорее всего, чревато очередными граблями.
В итоге же все это комсомольское путешествие оказывается всего-лишь следствием одного из возможных решений специфической проблемы автора и совсем не обязательно разламывать управление кешированием HTTP из-за того, что какой-то программист однажды накосячил. Так что рекомендую воспринимать эту статью с хорошей долей grain of salt и думать самостоятельно о последствиях отключения чего-либо.
что собственно и произошло, судя по описанию на сайте виновника торжества.
Цитирую:
I would like to especially acknowledge Douglas Crockford's work on JSLint. This lint is itself written in Javascript and is an interesting and rather sophisticated script. Crockford's ideas about good coding practices served as a springboard for many of these lint rules.