Как показать клиенту новый сервер до переключения DNS

[ky0]

Ну и наркомания - заставлять ставить сомнительный плагин в браузер ради таких вещей.

Если уж настолько хочется показать с того же IP и домена - ну, не знаю, куку какую-нибудь секретную добавьте, отдаваемую по определённому урлу, с которой потом будет открываться тестовая версия сайта.

[zapimir]

А чем сомнительный, он прошел модерацию в обоих официальных сторах и Chrome, и Firefox, а там такого плана плагины проверяются весьма основательно и вручную.

Да и плагин всего 38 КБ включая иконки, использует стандартные средства браузеров PAC для Chrome, и Proxy API для Firefox. В самом плагине даже не используется обфускация и минификация JS, т.е. скачав расширение из стора можно спокойно прочитать исходник, даже комменты в коде оставлены. Кроме того шлюзы работают, без MITM, т.е. сохраняется End-to-end шифрование и они не могут видеть трафик.

[aol-nnov]

https://staging.example.net, но тогда не получится пропиарить “эл семь админ гард” в конце статьи, да и статьи-то не получится… сплошные минусы! ))

[AVX]

А что насчёт линуксовых машин? Мне казалось, что преобразование имя-айпи выполняет системный резолвер, а он может быть разным на разных дистрибутивах или даже просто один и тот же дистр по-разному настроен. Расширение браузера забирает эти функции на себя? Браузер перестаёт использовать системные библиотеки для этих целей? Кэширование разрешения имён не влияет тут?

[Naves]

По умолчанию в Linux браузер Mozilla Firefox может игнорировать настройки из /etc/resolv.conf из-за включенной функции DNS через HTTPS (DoH / TRR). В режимах защиты по умолчанию браузер часто отправляет запросы через внешние защищенные серверы (например, Cloudflare), минуя локальный системный резолвер.

[AVX]

А это поведение как-то можно контролировать? Выглядит небезопасно, когда браузер разрешает имена в стороннем сервисе.

[JBFW]

Скорее наоборот, браузер разрешает имена там где они реально работают, а не где местный админ понакрутил...

[AVX]

Может это для обычных юзеров и норм, но для корпоративного применения - ровно наоборот, нужно чтобы всё было под контролем, а не так, чтобы браузер лез на хз какие сервера днс, кроме заданных админом.

[JBFW]

Эту задачу можно решить на уровне nginx на сервере:

Задаем два апстрима, один рабочий, а другой новая версия:

upstream backend_real {
  server10.1.0.1:8080;
}
upstream backend_test {
  server10.1.0.2:8080;
}

Мапим юзеров по их адресу (remote_addr):
Для всех - рабочий сервер, для контрольной группы (или конкретных IP) - тестовая версия

map $remote_addr $backend {
  default backend_real;
  192.168.1.0/24 backend_test;
}

И потом просто отправляем кого куда:

server {
 ...
 ...

  location / {
    proxy_path http://$backend;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-HTTPS 0;
    proxy_set_header Referer $http_referer;
  }
}

Всё, контрольная группа тестирует, если все ОК - переключаем апстрим на новый, старый можно сохранить на случай срочного отката, потом убрать.