Как они это сделали?

Вот так он узнал разницу между HTTP и HTTPS

Вроде в ответе техподдержки провайдера всё написано.

Подключен корпоративный VPN поднятый на этом же самом сервер. Ты этот момент пропустил? Или я чего-то недопонимаю?

Попробуй более длинный ключ.

но скорее банальный ДНС-утечка, настроенный шибко мудреным и прошареным админом, т.е. тобой :-)))

Скорее всего запросы к DNS у тебя не через корпоративный прокси идут. А там открытый протокол. Распарсили и вернули тебе нужный IP, потому что их DNS ближе. А потом дело техники. Ты переходишь по урлу, они урл сохраняют, хост тоже. Показывают открытку и редиректят куда надо.

Вообще ничего не настраивал мудренно и прошарено - настроил подключение VPN (оно мне необходимо по работе, так на некоторых ресурсах у нас фильтрация по IP) из файла ovpn и указал в настройках network-manager’а DNS. Вот и все настройки которые я сделал.

Ну да - DNS само по себе. Просто фрином и гугл. А как кстати узнать какой DNS в реальности вернул мне IP?

Мы надеемся ты пошлешь им новогоднюю открытку с черкашом внутри? Музыкальную. Иначе какой смысл тебе помогать. Пообещай.

Аристоклий

Насколько я понимаю, при https такого не будет.

DNSы в настройках сети 80.80.80.80, 8.8.8.8, 8.8.4.4…
mysite.ru

Как у тебя ресолвится домен с включенным впн и без него?

А как кстати узнать какой DNS в реальности вернул мне IP?

Теперь уже никак. Но ты же можешь ещё поэкспериментировать.

Насколько я понимаю в данном случае пофиг. Потому что домен-то все равно виден в запросе. При включенном https они просто тебя назад вернуть не смогут на url и вернут просто на домен.

Как у тебя ресолвится домен с включенным впн и без него?

Боюсь я не понимаю вопроса.

Теперь уже никак. Но ты же можешь ещё поэкспериментировать.

Почему «Теперь»? А что произошло? Я же могу попробовать другой домен? Дело в том что на все запросы nslookup я вижу что отвечает мне 127.0.0.1 - а как мне увидеть какой ДНС мне прислал реальный ответ, самому кэширующему серверу на машине?

Потому что домен-то все равно виден в запросе

Если SNI включено. На этот сайт есть доступ из «дикого» интернета? Натрави на него SSL Server Test.

Боюсь я не понимаю вопроса.

dig domain.tld
например. Там чуть больше информации. При включенном и выключенном vpn.

Дело в том что на все запросы nslookup я вижу что отвечает мне 127.0.0.1

Посмотри какой процесс тебе отвечает на запросы
netstat -lnp | grep ':53'

Почему «Теперь»?

Потому что уже поздно что-то где-то искать.
А так ты можешь хотя бы tcpdump или wireshark запустить и смотреть, кто и что тебе возвращает.

как мне увидеть какой ДНС мне прислал реальный ответ, самому кэширующему серверу на машине?

Твой кеширующий сервер может огласить источник? Записать его в логи? Наверняка нет.

У тебя убунта вроде бы?

отвечает мне 127.0.0.1

Если система с systemd то есть ещё полезная команда resolvectl status

По UDP, наверное, никак.

Если не DNS over https, то будет.

DNSы в настройках сети 80.80.80.80, 8.8.8.8, 8.8.4.4…

Пропингуй эти адреса. Пропингуй свой сервер с VPN. Пропингуй эти же адреса напрямую с сервера с VPN. Если time прямого пинга меньше чем время до VPN + время от VPN до DNS - то у тебя утечка DNS. Если время совсем маленькое, сравнимое с пингом до провайдерского шлюза - то твой провайдер перехватывает трафик на гуглоднс и подставляет свой DNS, где и подсовывает тебе страничку.

Если провайдер заруливает только 53 UDP то для надёжности повторить это с dig @DNS_IP somehost.com, смотреть строчку Query time

ДНС-утечка

Dns и http они точно перехватывают и подменяют. https тоже, но просто сбрасывают. Перенаправление на уровне http делают, вроде. На уровне dns сломали бы слишком многое, да и проверено, что с надежным dns перенаправление тоже происходит. Перенаправляют, кстати, только с корневой страницы, так что автоматику это практически не ломает.

Если SNI включено. На этот сайт есть доступ из «дикого» интернета? Натрави на него SSL Server Test.

Да там нет SSL воообще. Это тестовая площадка.

dig domain.tld

например. Там чуть больше информации. При включенном и выключенном vpn. Без VPN: https://pastebin.com/Sp8rrZXQ C VPN: https://pastebin.com/j9WMZwdY

У тебя убунта вроде бы?

Она.

Если система с systemd то есть ещё полезная команда resolvectl status

Не настолько новый systemd, но

> systemd-resolve status
status: resolve call failed: No appropriate name servers or networks for name found

80.80.80.80 Пинг без VPN: 46.368 Пинг с сервера на котором VPN: 10.927 Пинг c VPN: 81.748

8.8.8.8 Пинг без VPN: 41.448 Пинг с сервера на котором VPN: 4.841 Пинг c VPN: 75.678

Похоже все нормально.

Это была подмена dns ответа.
Блокируй 53 порт на wan, ставь dns внутри локалки, получай dns записи на свой dns по шифрованным каналам.

1. Разводишь как можно больший скандал.

2. Меняешь провайдера с ДОМ.сру на нормального.

3. ...

4. profit!

www.dnsleaktest.com

Дом.ру перехватывают и подменяют запросы dns.
Именно поэтому я уже давно использую DNS-over-TLS, чего желаю и вам.

Блин, не в доме нормального провайдера :( Только ДОМ.ру.

С VPN: https://i.imgur.com/0WsEUY8.png

Без него: https://i.imgur.com/7ZjQDkO.png

Именно поэтому я уже давно использую DNS-over-TLS, чего желаю и вам.

Пошел читать...

Еще можно DNS-over-HTTPS, что больше понравится)

А dig что говорит? Может провайдер только 53 порт к себе заруливает, а ICMP не трогает.

Получается, что нет подмены днс, постоянной во всяком случае.

У одного мобильного оператора заметил, ставишь на клиенте 8.8.8.8, а получаешь совсем другие DNS, принадлежащие оператору.

Да тоже вроде все норм. С сервака 11 msec, с VPN 165, без - 103.

Кажется мой роутер не умеет такого. Придется на клиентах делать.

Что для роутера выбрать DOH или DOT, что беспроблемнее и проще? Какого провайдера dns выбрать?

Это очень плохо. А вы пробовали звонить другим провайдерам?

systemd-resolve --status.

Подключен корпоративный VPN поднятый на этом же самом сервер.

на этом же самом сервер.

Причина в этом. До адреса твоего сервера трафик идет не через впн, а в открытую. Иначе нельзя, т.к. будет петля в правилах маршрутизации.

Как вариант, попробуй обращаться не на внешний адрес, а на внутренний адрес в тоннеле. Нужные адреса можно поменять через hosts.

а что в /etc/resolv.conf?

Она.

Написал бы какая. Может не пришлось бы в угадайку играть.
У тебя 127.0.0.1:53 кто слушает? systemd-resolved?
Какие настройки в /etc/systemd/resolved.conf?
Ссылка такая есть?
/etc/resolv.conf -> /run/systemd/resolve/resolv.conf
Что внутри /etc/resolv.conf

DNS-over-TLS

я пользуюсь kresd

https://github.com/DNSCrypt/dnscrypt-proxy/ вместо тысячи слов

вместо тысячи слов

Тысяча отвалов.

https://pastebin.com/n4S0sne0 - без vpn. https://pastebin.com/3dV1r3bR - с vpn: странно что фриномовский исчезает. Или нет?

Это очень плохо. А вы пробовали звонить другим провайдерам?

Конечно. Я с этого начал когда переехал в эту квартиру. Периодически задалбываю МТС.

Написал бы какая. Может не пришлось бы в угадайку играть.

Дык дефолтная же - последняя LTS, т.е. 18.04

У тебя 127.0.0.1:53 кто слушает? systemd-resolved?

Ага - 821/systemd-resolve. Только 127.0.0.53:53. И UDP и TCP.

Какие настройки в /etc/systemd/resolved.conf?

Никаких - сплошные коммент. Секция [Resolve] выглядит так:

#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

Что внутри /etc/resolv.conf

nameserver 127.0.0.53
options edns0

Причина в этом. До адреса твоего сервера трафик идет не через впн, а в открытую. Иначе нельзя, т.к. будет петля в правилах маршрутизации.

Странно - я полагал что соединение идет через VPN все равно. Но черте возьми - ты прав!!! В $_SERVER REMOTE_ADDR - ip провайдера, а не VPN!

И нет HTTPS там. Вот оно!

Как вариант, попробуй обращаться не на внешний адрес, а на внутренний адрес в тоннеле. Нужные адреса можно поменять через hosts.

Разумно. Или VPN перенести на другой сервак, как уже давно думаю...

Никаких - сплошные коммент.

Значит используются захаркоженые настройки. И наверняка это 8.8.8.8. Который перехватывается провайдером.

Секция [Resolve] выглядит так:

Тогда ставь kresd, вешай его куда-нибудь на 127.0.0.2:53, и
DNS=127.0.0.2
FallbackDNS=127.0.0.2
в /etc/systemd/resolved.conf
Будет у тебя и dns-over-tls и совместимость с nspawn (если используешь) и всяким добром, которое хочет systemd-resolved.

В $_SERVER REMOTE_ADDR - ip провайдера, а не VPN!
И нет HTTPS там.

Прямо первый комментарий в теме — в яблочко!