Я хз, но был удивлён тем, что мой местный ростелеком не может в блокировку https, хотя местный же билайн может.

Возможно тебе просто гугловские днс заблочили, у нас местные иногда так делают.

Вообще пора на DNScrypt переходить и не гадать блочат там тебя или нет.

Яндексовский тоже блочится, плюс я попробовал рандомный что нашёл в интернет.

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

Многие провайдеры сейчас блочат все DNS кроме своих, по той же причине.

Яндексовский тоже не работает, плюс я попробовал рандомный днс что нашёл в интернет.

Если действительно блочат, почему на магистрали прямо?

А DNS провайдера работают?

что мой местный ростелеком не может в блокировку
https, хотя местный же билайн может.

Блокировку, или MITM ? Я слышал, что для школ они (Ростелеком) вполне себе MITM делают и смотрят вовнутрь пакетиков.

А DNS провайдера работают?

Какого провайдера? Я говорю это VPS. Из коробки в resolv.conf прописаны гугловские и яндексовские днс. А днс хостера только домены комментов ресолвит наверное.

Теперь еще и DNS впнить? :(

А если dnsmasq накатить?

комментов

клиентов

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

Не разбираюсь, имею в виду что по https заходит на заблокированные сайты.

А что говорит OpenDNS: 208.67.222.222 208.67.220.220

Тоже не работает.

Так мимо проходил..

Без ключа -U нормально доходит до цели.

А разве по дефолту он не включен?

А тупо пинги идут?

Да, ещё - шлюзы пигуются?

Пинги идут, я первым делом и проверил.

А разве по дефолту он не включен?

Ман говорит что нет, по умолчанию он шлёт udp на какие-то рандомные порты. Ключ -U шлёт UDP пакеты на 53 порт.

имею в виду что по https заходит на заблокированные сайты.

Ну так и должно быть. Вовнутрь https без MITM не посмотреть. Потому либо блокировать по IP весь https, скажем, Гугля и прочих крупных хостеров и иметь головняк с клиентами, либо всё пропускать, либо организовывать MITM и выслушивать от клиентов вопросы «а что это за фигня, зачем браузер ругается».

судя по картинке жалоб в интернетах - идёт какое-то выборочное и региональное тестирование некой системы.
т.е. ты уже N-дцатый с такими симптомами.

Вариантов решения тоже не много:
1) Дождаться пока переколбасит, это на пару дней всего.
2) Что-то делать со своим подключением и ДНС.

Нащёт митмов - походу эта «некая система» умеет и в это дело, частенько следом бежал товарный вагон с варнингами от браузеров.

да, всё пингуется трацетЬся и тд и тп.

именно подсаживаются на 53й порт и пока-пока.

судя по картинке жалоб в интернетах

А где это всё? Вроде всё тихо.

Накатать жалобу хостеру, не?

Некогда было, позже напишу.

имхо с этого надо начинать, а не на лоре жалобы строчить :)

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

да не, пару месяцев назад было дело.
оно как-то по ргионам бегали эти аномалии.

Запускаем dig параллельно tcpdump, смотрим результат tcpdump, тыкаем в морду хостеру...
ЗЫ Вот представьте если бы у вас там свой днс крутился, на дофига зон для овер-много клиентов, они бы легли все.

Потестил с помощью nc и другого моего сервера. Выяснил что исходящие пакеты достигают сервера, а ответы не доходят. То есть проблема только с входящими udp пакетами с 53 порта. tcp ходят нормально, также нет проблем с udp с других портов.

В ТП написал, жду...

У меня Ростелеком по команде traceroute -U 8.8.8.8 выдает следующее: http://pastebin.com/raw/NiLa1BxG

Если я правильно вас понял суть раскопанной вами проблемы заключается в подмене DNS? Поясните полученный вывод, интересно.

В вашем случае проблема не в Ростелекоме вроде. По крайней мере судя по трейсу последний шлюз гугловский.

Виноват ли Ростелеком я пока не уверен. К примеру, трейс до DNS яндекса:

traceroute -U -n 77.88.8.1
traceroute to 77.88.8.1 (77.88.8.1), 30 hops max, 60 byte packets
 1  94.142.139.1  9.291 ms  9.277 ms  9.421 ms
 2  * * *
 3  * * *
 4  90.154.106.66  1.321 ms  1.296 ms  1.091 ms
 5  87.250.239.62  2.334 ms 87.250.239.22  2.468 ms  2.406 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
...
30  * * *

Трейс до другого личного сервера, где поднят Bind9:

traceroute -U -n x.x.x.x
traceroute to x.x.x.x (x.x.x.x), 30 hops max, 60 byte packets
 1  94.142.139.1  0.726 ms  0.702 ms  0.689 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
...
30  * * *

К слову, нормальные трейсы без -U (т.е. тоже UDP пакеты, но на рандомные порты) с этого же сервера выглядят так:

⟫ traceroute -n 77.88.8.1
traceroute to 77.88.8.1 (77.88.8.1), 30 hops max, 60 byte packets
 1  94.142.139.1  9.000 ms  9.029 ms  9.060 ms
 2  * * *
 3  * * *
 4  90.154.106.66  1.185 ms  1.170 ms  1.128 ms
 5  87.250.239.22  2.501 ms  2.463 ms  2.784 ms
 6  * * *
 7  77.88.8.1  2.295 ms  2.543 ms  2.488 ms

⟫ traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  94.142.139.1  1.689 ms  1.747 ms  1.781 ms
 2  * * *
 3  217.107.80.74  1.056 ms  1.053 ms  1.018 ms
 4  * * *
 5  8.8.8.8  1.543 ms  1.270 ms  1.714 ms

Шома о чём-то похожем поднимал тему недавно

#cast Shaman007

ТП в ответе дал IP их собственного DNS, он работает. Почему не работают другие не сказали.

Напишите им что вам нужно использование своих dns и такой вариант вас не устраивает. Пускай разбираются.

Я знаю, что Ростелеком одно время поддельными сертификатами баловался, сейчас вроде прекратили, по крайней мере я больше не видел. Сейчас капчой замучали, гугл постоянно плюется. Чтобы это значило?

Сейчас капчой замучали, гугл постоянно плюется. Чтобы это значило?

Вангую nat вашего прова.

Ну, капчу Гугл показывает при гуглинге обычно пользователям за натом, т.к. получается так что с одного IP приходит слишком много запросов. Наверное Ростелеком посадил вас на NAT (несколько пользователей сидят за одним IP).

Напишите им что вам нужно использование своих dns и такой вариант вас не устраивает. Пускай разбираются.

Ну я у них спросил в более вежливой форме, сказали «Проблема у нас, мы ее решаем.»

Возможно под какой-то днс флуд они попали, поэтому и закрыли на вход. Я сам попадал на такое. Недавно (несколько месяцев назад) про что-то жесткое Iron_Bug здесь писала.

Наверное Ростелеком посадил вас на NAT (несколько пользователей сидят за одним IP).

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

Вот тут уже дальше шлюза хостера не идёт, я так понимаю.

Да именно так. Было у меня такое как-то, помимо этого сопровождалось потерями пакетов и высоким пингом. Кстати пинг от разных провайдеров до google DNS разный, не берусь утверждать что-либо, но исходя из собственных ощущений, DNS от гугла раньше работал реально быстро, разница была очень даже заметна в сравнении с другими dns, пинг был в пределах 8-12ms, сейчас в среднем 70-100 и гугл днс стал работать ничуть не быстрее днсов провайдера. Вобщем-то я сомневаюсь, что это dns гугла стар работать медленнее, скорее всего таки трафик перехватывают и на этом узле создаются подобные задержки.

Сейчас погонял

traceroute -U 8.8.8.8

у меня тоже не дошло до конца

traceroute -U 208.67.222.222

дошло

dig @8.8.8.8

работает на ура

Возникает вопрос: Правомочна ли оценка работоспособности DNS сервера с помощью traceroute -U ?

Да гугл, вообще со своей капчей болен на всю голову. Он и на одном ip может ее выкатить, причем похоже где-то у него таймауты прописаны, т.е. будет эту капчу показывать на протяжении н-часов еще. До сих пор не определил причин, есть только предположения или при частой смене ip (включал выключал впн) или при одновременном частом заходе из разных браузеров.

Мерить пинг до 8.8.8.8 смысла нет, физически это куча серверов расположенных в разных местах, т.е. в разное время это могут оказаться разные машины с разными путями до них.

Да, поднимал, да, фильтрует.

Теперь я проверить, понятно, уже не могу.