Указатель для браузера что сайт имеет несколько ip адресов
Я интересуюсь ТОЧНОЙ информацией, например (но не ограничиваясь этим):
- Будет ли браузер получать 2 IP-адреса от ОС, или он получит только один?
- Какой IP-браузер будет использовать браузер сначала (случайный или всегда первый)? Теперь предположим, что браузер начался с неудачного ip1
- Как долго браузер будет использовать ip1?
- Если пользователь нажимает «stop», пока он ждет ip1, а затем обновляет
- какой IP-браузер будет работать?
- Что произойдет, когда он отключится - начнется ли попытка ip2 или дать ошибку? (И если ошибка, которую ip будет пытаться использовать браузером, когда пользователь обновление кликов).
- Когда пользователь нажимает кнопку «Обновить», любой браузер попытается найти новый DNS-запрос?
Теперь предположим, что браузер сначала попытался работать с ip2.
- Для следующего запроса страницы браузер будет использовать ip2, или он может случайно переключатель ips?
- Как долго браузеры сохраняют IP-адреса в своем кеше?
- Когда браузер отправляет новый DNS-запрос и получает SAME ips, будет ли он ПРОДОЛЖИТЬ использовать тот же самый известный для работы IP, или процесс начинается с царапины и может попробовать любой из двух?
Конечно, все это зависит от браузера, а также может варьироваться между версиями и платформами, я был бы рад иметь максимум деталей.
Цель этого - я пытаюсь понять, что именно пользователи будут испытывать при использовании циклического DNS-сервера и одного из хостов.
Пожалуйста, я не спрашиваю о том, насколько плохая балансировка нагрузки DNS, и, пожалуйста, воздержитесь от ответа «не делай этого», «это плохая идея», «вам нужно сердцебиение /прокси /BGP /что угодно» и и так далее.
2 ответа
В конце концов, мне пришлось самому «исследовать». Вот поведение Chromium (версия 12.0.742.112) (работает на ubuntu 11.04):
Одна интересная вещь - попытка подключения TCP не отбрасывается, когда пользователь нажимает на отмену - то есть, когда я нажимаю кнопку «Отмена», и через 60 секунд нажмите «Повторить», страница будет отображаться через 130 секунд (189 с первой попытки). Но если я нажму отмените и нажмите «Обновить» после 190 секунд, процесс начнется с самого начала.
Относительно элементов исходного вопроса:
- Браузер получает оба IP-адреса от ОС, ОС не изменяет порядок IP-адресов.
- Браузер всегда пытается подключиться к ip, который появляется первым
- Он пробует 189 секунд.
- При 2-й попытке он снова попробует первый IP-адрес.
- Когда первый тайм-аут IP, браузер молча продолжает второй ip. Если он работает - отображается страница, если нет - ожидание продолжается.
Вместимость: 100 Время ожидания (мс) для записей успеха: 60000 Время ожидания (мс) для записей о сбоях: 0
Если работает первый IP-адрес, процесс будет таким же, и он всегда будет успешным с первой попытки.
Вместо того, чтобы рассказывать людям, чего вы не хотите, почему бы не объяснить, что именно вы пытаетесь достичь?
Если все, что вам нужно, - это известные данные, тогда идите и исследуйте себя, или прочитайте документацию о любом браузере (есть сотни), о котором вы говорите.
Это может помочь вам узнать, что это не имеет ничего общего с DNS.
Если браузер получает запрос, он сначала просматривает различные кеши, чтобы узнать, присутствует ли URL-адрес или URL-адрес, а не имя хоста. Если нет, это приведет к удалению системного распознавателя для разрешения имени хоста.
Если возвращаемый IP-адрес не отвечает, он, безусловно, будет кэшировать его внутренне как результат отрицательного результата поиска , поэтому он снова запрашивает тот же URL-адрес снова в надежде попасть в другую запись A для он, вероятно, не будет иметь никакой цели, поскольку он сохранит результат имени хоста вместе с отрицательным результатом IP.
Или, вы знаете, вы могли бы предоставить дополнительную информацию.
EDIT: Я вижу, что вы предоставили некоторую информацию между всеми требовательными и smartassery.
- Если браузер запрашивает системное решение для имени хоста, он вернет любую информацию для этого имени хоста. Если это означает 2 IP-адреса, тогда он вернет 2 IP-адреса.
- Это зависит от браузера.
- Это зависит от браузера, но все браузеры, которые я когда-либо использовал, делают один запрос и будут тайм-аут после стандартного тайм-аута TCP CONNECT (); Я довольно уверен, что там есть RFC .
- Это зависит от браузера. Он не имеет ничего общего с DNS или сетью.
- Нет.
- Нет.
Вы также не знаете, что DNS-записи кэшируются везде, особенно на клиентах. Эти записи истекают, в зависимости от того, что предполагал владелец домена, или кэшей между вами и вами. Один час до одного дня является обычным явлением, поэтому не ожидайте, что распознаватель сделает другой DNS-запрос, если вы нажмете обновление, как сумасшедший.
Работа в Twitter одновременно под рабочим и личным аккаунтами. Фото: Mozilla
Ходят слухи, что на некоторых сайтах какие-то пользователи пишут одновременно под несколькими аккаунтами. Они якобы оставляют однотипные комментарии под разными никами. Игроки в покер и другие онлайн-игры жалуются, что соперники играют как будто сообща, словно договорившись разорить жертву.
Правда это или нет, но в экспериментальной сборке браузера Firefox Nightly только что реализована технология, которая сильно упрощает одновременную работу под несколькими аккаунтами. Теперь для этого не придётся заводить несколько виртуальных машин или открывать несколько браузеров: изоляция окружений реализована непосредственно между вкладками!
Разработчики Mozilla вчера представили новую функцию Contextual Identities для браузера Firefox 50 Nightly.
Формально, изоляция окружений (контейнеры) в Firefox создана для того, чтобы пользователь мог легко отделить свои аккаунты по нескольким сферам. Например, личные, рабочие, финансовые, шоппинг. Соответственно, открывая новую вкладку, пользователь сразу выбирает, из какого контейнера она будет работать.
Идея разработчиков в том, чтобы люди могли защитить свои конфиденциальные данные, если работают на одних и тех же сайтах из разных контейнеров. То есть в истории поисковых запросов для работы не должны появляться конфиденциальные данные, которые имеют отношение к личной жизни человека.
Теоретически, такая изоляция профилей повышает безопасность информации. Например, все финансовые данные и профили хранятся в «банковском» контейнере. Таким образом, при посещении сомнительного сайта из личного контейнера не произойдёт утечки финансовой информации через возможную XSS- или CSRF-атаку. Дополнительная изоляция здесь совсем не помешает.
У каждого контейнера внутри Firefox — свой собственный набор куков, собственный indexedDB, localStorage и кэш, собственная история сёрфинга и т.д. Получается, что если сайт открыт на вкладке из рабочего контейнера, то он не сможет получить доступ к кукам из личного контейнера. С другой стороны, различные вкладки из персонального контейнера будут использовать одни и те же куки, кэш и локальные базы данных.
По умолчанию, новые вкладки в в Firefox Nightly открываются как обычно, то есть как «общие» контейнеры. Чтобы получить изолированное окружение, пользователь должен вручную открыть вкладку внутри дополнительного контейнера. Для создания вкладки в новом контейнере есть несколько способов, в том числе через меню File – New Container Tab. Сейчас разработчики думают добавить ещё несколько способов открытия новой вкладки внутри контейнера, например, длительным нажатием клавиши “+” на клавиатуре.
В данный момент доступны контейнеры Personal, Work, Banking, Shopping. Каждый из них помечен своим цветом: синий, оранжевый, зелёный и розовый, соответственно, чтобы случайно не перепутать. Соответствующая цветная полоска размещается над указателем вкладки.
Для одновременной работы под несколькими аккаунтами удобно также завести каждому контейнеру отдельный IP-адрес (отдельный VPN), чтобы на сайте не догадались, что многочисленные пользователи принадлежат одному лицу. Возможно, в будущих версиях Firefox реализуют такую функцию, она была бы логичным продолжением идеи контейнеров Firefox.
Контейнеры — это, в своём роде, нечто среднее между обычным и приватным режимами сёрфинга в Firefox. Как известно, в режиме Private Mode при выходе из браузера или закрытии вкладки полностью стираются все куки, история и кэш, так что каждый раз начинается работа «с чистого листа».
Нужно иметь в виду, что некоторые сайты запрещают заводить несколько аккаунтов. Например, такое косвенно запрещено в правилах «Хабрахабра» (редакция от 16 мая 2016 года).
Вот список того, чего на ресурсе делать не следует.
Создавать виртуалов. Всегда приятно поговорить с умным человеком, но создавать для этого добавочные аккаунты и накручивать с них карму и голоса за публикации не стоит.
Как обычно, любые экспериментальные технологии организация Mozilla сначала опробует в Firefox Nightly, а затем на основании отзывов пользователей дорабатывает их, исправляет ошибки и очень часто доводит до реализации в стабильной версии браузера.
В данном случае ожидается широкая общественная дискуссия, потому что тема авторизации на сайтах под несколькими аккаунтами из одного браузера обсуждается давно: см. обсуждение в блоге Mozilla от 2010 года и статью от 2013 года для технического комитета IEEE по безопасности и защите конфиденциальных данных, опять от представителей организации Mozilla.
Предстоит решить несколько проблем, в том числе определить, насколько чётко и надёжно пользователи различают контейнеры друг от друга, не путают ли их. Другой вопрос — как разрешать ситуации, когда пользователь спутал контексты и зашёл в аккаунт из другого контейнера, следует ли реализовать функцию «отката» базы и куков с целью исправления ошибки? В принципе, пользовательские данные уже утекли, так что такой откат даёт только ложное чувство безопасности, возможно, его и не надо реализовывать.
Третий вопрос — должен ли браузер подсказывать пользователю, в какой контекст, то есть в какой контейнер лучше перенести новую вкладку и определённый сайт, чтобы пользователям не приходилась выполнять всю работу по управлению контейнерами самостоятельно? Если браузер должен помогать, то какие эвристики использовать для выполнения такой работы?
Mozilla надеется на помощь и подсказки сообщества в обсуждении этих проблем.
Своё мнение о контейнерах сейчас можно высказать, заполнив небольшую анкету.
Если всё пойдёт по плану, то контейнеры Contextual Identities могли бы появиться в стабильной версии Firefox 50, которая запланирована к выходу ориентировочно осенью 2016 года. Но разработчики считают, что контейнеры следует ещё дополнительно тестировать. В следующей версии Aurora/DevEdition 50 контейнеры не будут включены по умолчанию. На осень 2016 года запланировано более подробное исследование на добровольцах по программе Test Pilot.
Mozilla надеется, что новая функция будет полезна людям, которым раньше приходилось запускать второй браузер или несколько виртуальных машин. Теперь у них нет причин выходить из любимого Firefox.
Следует иметь в виду, что у сайтов всё равно остаётся возможность идентифицировать отдельных пользователей, которые пользуются разными аккаунтами. Для этого применяются техники фингерпринтинга, то есть составления «отпечатка» системы по сочетанию нескольких характеристик: версия ОС, user-agent браузера, набор установленных шрифтов, IP-адрес и многие другие. Недавно сайты начали применять более продвинутые техники для отслеживания пользователей: фингерпринтинг по рендерингу Сanvas, через Audio API, путём выявления реального IP-адреса через WebRTC Local IP, через список установленных шрифтов по Canvas-Font. Наилучший эффект даёт сочетание всех этих методов. По указанным ссылкам перечислены сайты из числа самых популярных сайтов интернета, где работают соответствующие скрипты для скрытого фингерпринтинга.
Так что для более надёжной анонимной работы лучше заходить на сайты через сеть анонимайзеров с использованием браузера Tor. Желательно также использовать операционную систему Tails, которая изначально настроена для безопасной работы в интернете. Именно этот дистрибутив Linux раньше использовал Эдвард Сноуден.
Здравствуйте. Для автоматизации моей небольшой задачки, чтобы вручную не перезагружать роутер каждый раз, нужен вариант открытия сайта через разные ip адреса. И не только ip, но и чтобы куки сбрасывались. Возможно реализовать такое в хроме? Или какие вообще есть варианты?
Нужно курировать сразу несколько аккаунтов, не выбивая при етом каждый раз личный кабинет + обязательное использование разных ip адресов (чтобы не смахивало на спам). Есть ли какие либо готовые варианты (все в одном) использования впн туннеля со сбросом куки?
- Вопрос задан более трёх лет назад
- 271 просмотр
Если вам важно скрыть связь между пользователями для сервера, то у вас только вариант с использованием прокси.
К браузерам есть расширения, позволяющие переключать прокси в один клик, но очень сложно будет не спалиться, ведь заходить придется с помощью приватных страниц, каждый раз закрывая их перед сменой прокси (иначе куки будут связывать пользователей друг с другом).
Настоятельно рекомендую запустить несколько браузеров с разными профилями одновременно, (firefox я запускаю под разными пользователями OS, так проще настроить, но у меня всего 2). В этом случае вы можете настроить разные темы, чтобы визуально контролировать, в каком именно браузере вы сидите.
Как бонус - одновременная работа.
p.s. чтобы одновременно работать под разными ip без использования прокси, то в linux нужно будет использовать cgroups или иные механизмы изоляции, а в общем любые виртуальные машины, на ваш вкус.
Спасибо. Одновременная работа это то, что мне и нужно. Мне так легче курировать все и сразу. Небольшая заминка лишь в том, что у меня на руках свыше 20 аккаунтов, которые должны быть открыты одновременно в 20 браузерах (насколько я понял) + с разными профилями. Это нокаут для оперативки, ну а 20 виртуалок это вообще смерть)))
Не понял лишь одного: Почему нужно запускать браузеры под разными профилями ОС? Как это взаимодействует между собой?.
Отчасти да, взаимодействуют, у меня не получилось последние версии firefox запустить одновременно несколько копий под одним пользователем, хоть и указывал разные профили.
Полагаю на linux этого не потребуется, там по уму используют иной способ контроля повторного запуска.
rPman, ну ФФ последней версии мне не особа нужна, я могу и на предыдущих сидеть. Мне главное чтобы работало.
P.S то есть в Линуксе возможно одновременно сидеть под разными браузерами не создавая отдельных пользователей ОС?
чтобы попробовать, вам нужно потратить минут 10 ;) загрузившись с liveusb/livecd или в любой виртуалке прямо из iso-шки
прописал в доменной зоне одному домену 3 ip адреса, смотрю в nslookup'е - выдаются все три ип, но порядок каждый раз разный. это для распределения нагрузки на сервера или что?как бы сделать, чтобы при недоступности первого ип, использовался второй? по типу MX для мыла.
>прописал в доменной зоне одному домену 3 ip адреса, смотрю в nslookup'е
>- выдаются все три ип, но порядок каждый раз разный. это
>для распределения нагрузки на сервера или что?
>
>как бы сделать, чтобы при недоступности первого ип, использовался второй? по типу
>MX для мыла.
в bind 9 отвечает за это опция rrset-order
возможные опции:
fixed
random
cyclic - эта по дефолту, если ничего не указано.
кстати fixed почему-то не работает, хотя вроде и должна и везде написано, что fully implemented
>прописал в доменной зоне одному домену 3 ip адреса, смотрю в nslookup'е
>- выдаются все три ип, но порядок каждый раз разный. это
>для распределения нагрузки на сервера или что?Вот что нашел ;)
http://zeus.sai.msu.ru:7000/internet/dns/khramtsov/10.shtml
Рассмотрим теперь случай, когда одному и тому же доменному имени присваивается несколько IP-адресов. Ситуация эта не такая уж и редкая. Пример, который лежит на поверхности - это корневые серверы доменных имен, т.е. серверы, которые обслуживают корневую зону.
Мы знаем, что их 13 и, что за каждым именем корневого сервера скрывается много машинный комплекс. У каждого из этих хостов свой собственный IP-адрес, следовательно, доменное имя соответствует нескольким IP-адресам.
Другой пример - хост выполняет функции шлюза. У него одно доменное имя, но каждый из интерфейсов имеет свой собственный IP-адрес, следовательно, одному имени будет соответствовать несколько IP-адресов.
Еще один пример - балансировка нагрузки на Web-серверах. Балансировка нагрузки через DNS - это, видимо, не самое оптимальное решение, но в качестве первого приближения решения проблемы оно проходит.
Предыдущее замечание относится главным образом к тому, что называют Round Robin алгоритмом. Существуют более оптимальные решения, построенные на основе DNS, например, RFC 1794, но они не реализованы в виде стандартных опций BIND.
>
>как бы сделать, чтобы при недоступности первого ип, использовался второй? по типу
>MX для мыла."Когда запрашиваются записи адресного типа, то клиенту (resolver или локальный сервер) возвращается список записей в том порядке, как они встретились в описании зоны. Именно в этом порядке прикладная программа и начинает проверять адреса с целью установки соединения."
- т.е. по идеи можно использовать на случай если первый ип в дауне.
>"Когда запрашиваются записи адресного типа, то клиенту (resolver или локальный сервер) возвращается
>список записей в том порядке, как они встретились в описании зоны.
>Именно в этом порядке прикладная программа и начинает проверять адреса с
>целью установки соединения."
>
>- т.е. по идеи можно использовать на случай если первый ип в
>дауне.потестил. не знаю о какой прикладной программе идет речь.. браузер ломится на разные ип =((
действительно SRV запись позволяет осуществить своего рода резервирование
в целях экспиремента проверил описание зоны .lanssh1 IN A 10.1.1.100
ssh2 IN A 10.1.1.2
ssh IN A 10.1.1.100
ssh IN A 10.1.1.2_ssh._tcp.ssh.lan. IN SRV 0 22 ssh2.lan.
_ssh._tcp.ssh.lan. IN SRV 1 22 ssh1.lan.по умолчанию ssh ssh.l ломится на 10.1.1.2 т.к. у него приоритет 0
если ssh на нем отключить, то ssh ssh.lan пытается подключиться на 10.1.1.100
>[оверквотинг удален]
>>>что бы в случае отсутствия одного обращение было на другой
>>>вопрос как его сделать ?
>>
>>_http._tcp.example.com SRV 0 0 80 www1.example.com
>>_http._tcp.example.com SRV 1 0 80 www2.example.com
>>_http._tcp.example.com SRV 2 0 80 www3.example.com
>
>По идее для браузеров данная схема не сработает, где-то читал что браузеры
>используют в своей работе А-запись, а не SRV. Или все-таки сработает?
>Сам кстати щас над этим бьюсь. Главно, правильно настроить.
У кого-то конечно работает: как по-вашему одноклассники.ку или яндекс открываются? там одна машина не справится, следовательно .Я бы не заморачивался если бы мой сервер, содержащий сервисы ftp, http, pptp и mail не был подключен к двум сетям одновременно. Одна - городская сеть, выход в интернет из нее предоставляется за доп. плату. Вторая, собственно все остальное - т.е. Интернет.
сервисы должны быть доступны и тем и другим. конечно, есть провайдеры, способные предоставить доступ к моему серверу по одному каналу и тем, и другим, но анлим с той же скоростью будет стоить уже совсем другие деньги.
а вот ДНС записи все же одни и те же, поэтому и надо использовать SRV, c обязательным разграничением приоритетности и одинаковым весом. тогда недоступность сервера по одному адресу отправляет клиента на сервер по другому адресу.>>_http._tcp.example.com SRV 0 0 80 www1.example.com.
>>_http._tcp.example.com SRV 1 0 80 www2.example.com.
>>_http._tcp.example.com SRV 2 0 80 www3.example.com.только вот надо не забыть для каждого сервера А записи еще создать
www1.example.com. IN A 10.0.0.1
www2.example.com. IN A 10.0.0.2
www3.example.com. IN A 10.0.0.3и еще рекомендуется такое делать
Называеццо "другие сервисы недоступны"*._tcp SRV 0 0 0 .
*._udp SRV 0 0 0 .
>> Почитайте что такое views в BIND и эта "проблема" у Вас отпадет.
>Сам кстати щас над этим бьюсь. Главно, правильно настроить.
>У кого-то конечно работает: как по-вашему одноклассники.ку или яндекс открываются? там одна
>машина не справится, следовательно .
>Боюсь, что Вы не до конца понимаете о чем говорите. У одноклассников нет SRV никаких, там обычный round-robin + устройства подобные этому http://www.barracudanetworks.com/ns/products/balancer_overvi.
> Вторая, собственно все остальное - т.е. Интернет.
> сервисы должны быть доступны и тем и другим. конечно, есть провайдеры, способные предоставить доступ к моему серверу по одному каналу и тем, и другим, но анлим с той же скоростью будет стоить уже совсем другие деньги.
> а вот ДНС записи все же одни и те же, поэтому и надо использовать SRV, c обязательным разграничением приоритетности и одинаковым весом. тогда недоступность сервера по одному адресу отправляет клиента на сервер по другому адресу.Почитайте что такое views в BIND и эта "проблема" у Вас отпадет.
С использованием views не за делегировать домен.
>> Почитайте что такое views в BIND и эта "проблема" у Вас отпадет.> Вы сами поняли что сейчас сказали?
> С использованием views не за делегировать домен.Вы сами поняли что сейчас сказали?
Файл зоны должен быть одинаковым у всех NS. Если я не прав приведите пример named.conf для данного случая.
Привет
Бьюсь над такой же проблемой
Хочу узнать результат, у Вас всё работает по данному принципу используя SRV ?
Удалось ли решить данную проблему
если да то как?
Использовал все комбинации с SRV но мои сайты не хотят быть доступны.
поднял внутри тестовую модель, результат отрицателныйс\у
Погуглил так и не нашел решения этой задачки.
Первый пришедший в голову вариант решения, таков:
Наше доменное имя делегируем на два IP адреса которые у нас есть от разных провайдеров.
У себя поднимаем сервачок с двумя виртуалками на каждой настраиваем свой DNS сервер. Каждый сервер доступен по одному из IP адресов в каждом DNS сервере своя запись соответствующая IP адресу через который он доступен.
Таким образом если один из каналов падает то один из ДНС серверов которому делегировано наше доменное имя недоступен, а следовательно запрос обработает доступный DNS у которого соответствующая запись.
Не знаю на сколько понятно объяснил, но по идее работать должно. Единственная возможная проблема это кэш у клиента.
Причем, экономим на абонплате за DNS поддержку имени и имеем отказоустойчивость. НО это все в теории, какие подводные камни в такой реализации могут быть? Кто что думает по этому поводу?
Должен признать, что идея остроумная. Правда резолвинг в случае падения канала будет сильно тупить.И самое большое "НО" -- вы исходите из неверной постановки задачи. Не нужно пытаться создать отказоустойчивость средствами DNS, для этого есть более удобные и надёжные инструменты. Для чего пытаться сделать из слона велосипед?
> Таким образом если один из каналов падает то один из ДНС серверов
> которому делегировано наше доменное имя недоступен, а следовательно запрос обработает
> доступный DNS у которого соответствующая запись.
> Не знаю на сколько понятно объяснил, но по идее работать должно. Единственная
> возможная проблема это кэш у клиента.
> Причем, экономим на абонплате за DNS поддержку имени и имеем отказоустойчивость. НО
> это все в теории, какие подводные камни в такой реализации могут
> быть? Кто что думает по этому поводу?
Задача сделать максимально удобный доступ для пользователей к серверу, который имеет несколько каналов от разных ISP. Какие надежные и удобные способы для этого есть? Буду очень признателен за ответ.> Должен признать, что идея остроумная. Правда резолвинг в случае падения канала будет
> сильно тупить.
> И самое большое "НО" -- вы исходите из неверной постановки задачи. Не
> нужно пытаться создать отказоустойчивость средствами DNS, для этого есть более удобные
> и надёжные инструменты. Для чего пытаться сделать из слона велосипед?
Читайте также: