mobilon

Очень странная проблема с интернетом

Рекомендованные сообщения

С апреля 2016 года сталкиваюсь с очень странной проблемой, попробую описать ее.

 

Я проживаю в г.Красноярске, подключен к сети Билайн уже 6 лет по одному и тому же адресу.

Использую следующее оборудование: WI-FI роутер TP-Link TL-WDR4300, MacBook Pro, iPhone 5.

 

Всегда все было хорошо, никаких проблем не возникало. Однако, с апреля 2016 г, самопроизвольно, примерно раз или два в месяц перестают открываться все сайты, имеющие физический хостинг за пределами г.Красноярска.

Соединение устанавливается, но ответ не приходит. В браузере это проявляется в виде сообщения "Соединено с <имя сайта>..." которое очень долго висит.

Команда telnet соединение с хостом на 80 порт устанавливает, дает возможность ввести команду, после чего также все просто висит без движения минут 20, TCP-соединение при этом не рвется:

 

MacBook-Pro-Evgenij:~ Hover$ telnet warandpeace.ru 80

Trying 212.113.124.22...

Connected to warandpeace.ru.

Escape character is '^]'.

GET /

 

Connection closed by foreign host.

 

Сайты, которые физически хостятся (или имеют зеркала или кэш-сервера) на оборудовании, которое *физически* расположено на площадках SIBIR-IX, RED-IX в г.Красноярске - открываются без каких-либо проблем.

В частности, открываются сайты newslab.ru, 24au.ru, sibdom.ru, mobilon.ru, admkrsk.ru, arban.ru, krasdom.ru, optibit.ru, webra.ru, rightside.ru и другие красноярские сайты (в том числе все из списка http://www.red-ix.ru/members/, http://www.sibir-ix.ru/abonent/), также открываются yandex.ru, mail.ru, youtube.com (как имеющие зеркала на площадках SIBIR-IX, RED-IX).

 

Если воспользоваться Яндекс.Браузером и его функцией проксирования трафика Яндекс.Турбо - то другие сайты (не красноярские) тоже начинают открываться, после выключения Яндекс.Турбо - перестают открываться.

 

Такие сервисы как почта (SMTP и POP3), Skype, Viber, WhatsApp - работают отлично, без каких либо замечаний.

И МакБук, и телефон, и компьютер на Windows демонстрируют аналогичный результат, т.е. дело точно не в них.

 

Если подключить кабель напрямую к компьютеру и установить VPN-подключение к Билайн с него - то все открывается.

 

Тех.поддержка отмахивается от проблемы, говоря, что у меня проблема с роутером, но я в этом не уверен, по следующим причинам:

 

1) В течение многих лет не было нареканий на работу интернета

2) Проблема возникает внезапно, также внезапно и пропадает

3) Перезагрузка роутера или его отключение проблему не решает

4) Перепрошивка роутера на последнюю прошивку проблему не решает

5) Проблема относиться *только* к ресурсам, физически размещенным за пределами площадок SIBIR-IX и RED-IX (подтверждено экспериментально)

 

Подозреваю, что проблема в работе L2TP сервера Билайна.

 

Огромная просьба разобраться в этой проблеме! Со своей стороны окажу всестороннюю помощь по ее разрешению.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@mobilon

Жаль, что Вы не показали маршрут до проблемных ресурсов в такой момент. Для Mac - это результат команды

traceroute warandpeace.ru

Как вариант, можно попробовать сменить MAC-адрес на внешнем интерфейсе роутера.

Изменено пользователем _Slava_

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@mobilon,оформите свое сообщение согласно первого в эту тему:

http://homenet.beeli...entry1065258676

 

@mobilon,

Если подключить кабель напрямую к компьютеру и установить VPN-подключение к Билайн с него - то все открывается.

Либо кривая маршрутизация в роутере, хотя может и в работе браса, т.к. происходит смена Ип при повторной авторизации.

В общем нужна трассировка ресурсов в проблемные моменты.

Изменено пользователем NikIv

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

...происходит смена Ип при повторной авторизации.

При перезапуске роутера это тоже происходит...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@_Slava_,

При перезапуске роутера это тоже происходит...

Логично :) , по этому и нужны для полноты картины результаты замеров.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@mobilon, если без роутера проблема не воспроизводится, то брас тут явно не при чем. Логично искать проблему в роутере.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

@eynard,

mobilon, если без роутера проблема не воспроизводится, то брас тут явно не при чем.

Не факт, вы сами знаете что было в свое время в брасами известного производителя.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не факт, вы сами знаете что было в свое время в брасами известного производителя.

Опа, опа! Пошла правда-матка. А что с ними было?

 

>to mobilon

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проблема самопроизвольно устранилась через час после опубликования этого поста.

 

@mobilon

Жаль, что Вы не показали маршрут до проблемных ресурсов в такой момент. Для Mac - это результат команды

traceroute warandpeace.ru

Как вариант, можно попробовать сменить MAC-адрес на внешнем интерфейсе роутера.

 

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

 

Да и причем тут маршруты, если TCP-соединение на 80 порт хоста нормально устанавливалось? Пакеты по нему уходили, но в ответ ничего не приходило.

 

 

@mobilon,

Если подключить кабель напрямую к компьютеру и установить VPN-подключение к Билайн с него - то все открывается.

Либо кривая маршрутизация в роутере, хотя может и в работе браса, т.к. происходит смена Ип при повторной авторизации.

В общем нужна трассировка ресурсов в проблемные моменты.

 

 

Роутер при авторизации получает что? Один маршрут по умолчанию? Или что-то еще?

Как может быть кривая маршрутизация в роутере, если вибер и скайп работают? Работет TeamViewer, AmmyAdmin?

 

...происходит смена Ип при повторной авторизации.

При перезапуске роутера это тоже происходит...

 

Да, совершенно верно

 

@mobilon, если без роутера проблема не воспроизводится, то брас тут явно не при чем. Логично искать проблему в роутере.

 

Разве подключение через компьютер осуществляется посредством L2TP?

 

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

 

Массовых обращений по этой теме нет и не будет, т.к. ваши операторы всем говорят, что у них все нормально. А по их мнению "все нормально" - это когда есть линк и L2TP-сесия поднята, а остальное их не волнует.

 

Не факт, вы сами знаете что было в свое время в брасами известного производителя.

Опа, опа! Пошла правда-матка. А что с ними было?

 

>to mobilon

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

 

В том случае ситуация не совсем аналогичная. Там IP выдавался динамически (у меня он был фиксированный), по wi-fi у него все работало и решилось это почему-то вбиванием ip вместо доменного имени в поле сервер авторизации (а скорее всего проблема так самопроизвольно устранилась, просто у человека это совпало с этим действием).

 

Я пробовал вписывать ip вместо имени - на возникновение и исчезновение проблемы это никак не влияет.

 

Хотя косвенно его пост подтверждает проблему в билайне с маршрутизацией - а иначе как объяснить, что выдача сервером определенных IP приводит к проблеме, а других - нет? Я вижу объяснение только в одном: основной шлюз, выдаваемый сервером авторизации не находится в подсети, выдаваемой eth интерфейсу роутера.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
...когда проблема была я маршруты смотрел, они были вполне нормальные, никаких зацикливаний, ничего странного я не заметил.

Да и причем тут маршруты, если TCP-соединение на 80 порт хоста нормально устанавливалось? Пакеты по нему уходили, но в ответ ничего не приходило.

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

Значит, это проблема какого-то фильтра, а не сети в целом.

Так как при исключении роутера из схемы все работает, то этого некорректный фильтр либо в роутере, либо в оборудовании провайдера, который по каким-то причинам не стыкуется с Вашим роутером.

С точки зрения оборудования провайдера основное отличие роутера от компьютера подключенного напрямую - это MAC-адрес внешнего интерфейса.

Именно поэтому я и просил его сменить. Лучше на MAC-адрес имеющегося компьютер, с которым проблем не было. Кстати, многие роутеры Dlink не могут работать в сети Билайн при использовании IPoE без изменения MAC-адреса.

...а иначе как объяснить, что выдача сервером определенных IP приводит к проблеме, а других - нет?

Просто разные IP-адреса выдают разные VPN-сервера.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а иначе как объяснить, что выдача сервером определенных IP приводит к проблеме, а других - нет? Я вижу объяснение только в одном: основной шлюз, выдаваемый сервером авторизации не находится в подсети, выдаваемой eth интерфейсу роутера.

Если бы так было, то не работало бы вообще ничего, а не только http.

 

а иначе как объяснить, что выдача сервером определенных IP приводит к проблеме, а других - нет?

объяснить можно например кривой работой pptp на роутере, а IP адреса - просто домыслы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@MoonFire

Точно, это фильтр именно http, например, для запрета доступа к заблокированным судом ресурсам! В роутере его точно нет. Определенно нужен тест со сменой MAC-адреса внешнего интерфейса роутера.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Точно, это фильтр именно http, например, для запрета доступа к заблокированным судом ресурсам!

Блокируют вроде по IP, а не по протоколам. Моя ссылка аж 2014 года, когда в билайне ещё не было такой повальной блокировки

 

В роутере его точно нет.

О да. http://www.tp-linkru.com/resources/simulator/TL-WDR4300/index.htm . Вкладка Access Control

 

Определенно нужен тест со сменой MAC-адреса внешнего интерфейса роутера.

Не понимаю при чём тут MAC.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@MoonFire

Простите, но мои наставнические навыки невелики, так что Вам вряд ли смогу объяснить. Но попробую...

При блокировке ресурсов фильтр идет и протоколу тоже. Многие заблокированные сайты легко открываются по https, конечно, если они его поддерживают.

Фильтр в роутере самопроизвольно не появится, именно поэтому я считаю, что его нет.

Из-за разного MAC-адреса подключение осуществляется на разные VPN-сервера.

При подключении по IPoE встречается случай использования одинаковых MAC-адресов роутерами Dlink, поэтому по неофициальной информации такие адреса занесены в "черный список".

 

P.S. Блокировка была и раньше, до "такой повальной блокировки". :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Из-за разного MAC-адреса подключение осуществляется на разные VPN-сервера.

На сколько я знаю, распределение по брасам зависит от нагрузки на них. При смене MAC - измениться только внутренний ip полученный по dhcp, хотя может щас как-то по другому.

 

При подключении по IPoE встречается случай использования одинаковых MAC-адресов роутерами Dlink, поэтому по неофициальной информации такие адреса занесены в "черный список".

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

Вообще по этой проблеме надо бы хорошенько вздрючить билайн, а не советовать всем подряд менять маки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@MoonFire

Выбор VPN-сервера осущестсвляется через разрешение имени tp.internet.beeline.ru

То есть фактически DNS-сервер распределяет нагрузку по брасам :)

Они просто заблокировали общеизвестные MAC-адреса роутеров Dlink.

Изменено пользователем _Slava_

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@MoonFire

Выбор VPN-сервера осущестсвляется через разрешение имени tp.internet.beeline.ru

То есть фактически DNS-сервер распределяет нагрузку по брасам :)

Они просто заблокировали общеизвестные MAC-адреса роутеров Dlink.

 

А как это объясняет работу с определеннымм диапазонами адресов из подсетей, входящих в определенные пиринговые точки?

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

Если бы MAC роутера был заблокирован, то наверно вообще ничего бы не работало?

 

@MoonFire

Точно, это фильтр именно http, например, для запрета доступа к заблокированным судом ресурсам! В роутере его точно нет. Определенно нужен тест со сменой MAC-адреса внешнего интерфейса роутера.

 

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

 

а иначе как объяснить, что выдача сервером определенных IP приводит к проблеме, а других - нет? Я вижу объяснение только в одном: основной шлюз, выдаваемый сервером авторизации не находится в подсети, выдаваемой eth интерфейсу роутера.

Если бы так было, то не работало бы вообще ничего, а не только http.

 

 

Я не совсем корректно выразился. Я имел ввиду, что возможно сервер l2tp выдает помимо основного шлюза также набор подсетей, с маршрутами на них. Например, пиринговые сети. А основной шлюз при этом в какой-то момент времени выдается неправильный. В этом случае пиринговые ресурсы работать будут, а все остальное - нет.

 

а иначе как объяснить, что выдача сервером определенных IP приводит к проблеме, а других - нет?

объяснить можно например кривой работой pptp на роутере, а IP адреса - просто домыслы.

 

Почему тогда нормальная работа pptp на роутере не восстанавливается при его перезагрузке?

 

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

Значит, это проблема какого-то фильтра, а не сети в целом.

Так как при исключении роутера из схемы все работает, то этого некорректный фильтр либо в роутере, либо в оборудовании провайдера, который по каким-то причинам не стыкуется с Вашим роутером.

С точки зрения оборудования провайдера основное отличие роутера от компьютера подключенного напрямую - это MAC-адрес внешнего интерфейса.

Именно поэтому я и просил его сменить. Лучше на MAC-адрес имеющегося компьютер, с которым проблем не было. Кстати, многие роутеры Dlink не могут работать в сети Билайн при использовании IPoE без изменения MAC-адреса.

 

Вот это совершенно не очевидно. TCP-соединение устанавливается при получении инициатором его создания SYN+ACK, но это не гарантирует, что дальше все будет работать нормально. Например, в случае использования transparent proxy, клиент получит эти флаги, и соединени создастся, только оно создастся не с реальным хостом, а с proxy. А если proxy работает не корректно, то он может и ничего не передавать по этому соединению.

 

...а иначе как объяснить, что выдача сервером определенных IP приводит к проблеме, а других - нет?

Просто разные IP-адреса выдают разные VPN-сервера.

 

Конкретно в моем случае белый адрес был фиксированный и выдавался один и тот же.

Изменено пользователем mobilon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@mobilon,очень много слов и ни одного результата замеров подтверждающих проблему....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@mobilon

Помогать Вам больше совсем не хочется...

Потому что Вы возражаете лишь ради возражений.

И не хотите принимать помощь.

Изменено пользователем _Slava_

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@mobilon,очень много слов и ни одного результата замеров подтверждающих проблему....

 

Так проблема уже исчезла, также внезапно, как и появилась. Не могу сделать никаких замеров...

 

@mobilon

Помогать Вам больше совсем не хочется...

Потому что Вы возражаете лишь ради возражений.

И не хотите принимать помощь.

 

С чего Вы решили, что я возражаю? :)

Я просто спросил, как то, или другое могло повлиять на первое и второе :)

 

Мак я еще не пробовал менять, конечно попробую это сделать в следующий раз, когда эта проблема снова возникнет (в чем я не сомневаюсь, так как она уже возникала минимум 5 раз за последние 4 месяца). Просто интересно, как может заблокированный мак обеспечить нормальную работу одних ресурсов и блокировать работу других.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проблема возникла снова.

 

Прошу обратить внимание на то, что маршруты до всех сайтов, которые открываются, имеют 4й хоп c76peer-core-2.ranetka.ru (80.255.150.114). А маршруты до сайтов, которые не открываются имеют 4й хоп c76ext-core-2.ranetka.ru (80.255.150.116). Смею предположить, что HTTP фильтрация осуществляется на c76ext-core-2.ranetka.ru (80.255.150.116)

 

Для примера вот некоторая диагностическая информация:

 

ELDORADO.RU - не открывается:

 

 

ping eldorado.ru

PING eldorado.ru (178.248.235.20): 56 data bytes

64 bytes from 178.248.235.20: icmp_seq=0 ttl=55 time=61.206 ms

64 bytes from 178.248.235.20: icmp_seq=1 ttl=55 time=61.207 ms

^C

--- eldorado.ru ping statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 61.206/61.207/61.207/0.000 ms

 

traceroute to eldorado.ru (178.248.235.20), 64 hops max, 52 byte packets

1 192.168.0.1 (192.168.0.1) 0.907 ms 0.688 ms 0.719 ms

2 * * *

3 80-255-149-25.ranetka.ru (80.255.149.25) 4.001 ms 1.474 ms 1.492 ms

4 c76ext-core-2.ranetka.ru (80.255.150.116) 1.530 ms 1.528 ms 1.502 ms

5 195.239.180.97 (195.239.180.97) 2.458 ms 1.851 ms 1.855 ms

6 pe26.moscow.gldn.net (79.104.225.57) 65.989 ms

pe26.moscow.gldn.net (79.104.225.59) 58.631 ms

pe26.moscow.gldn.net (79.104.225.57) 61.861 ms

7 mskn08.transtelecom.net (217.150.48.182) 62.986 ms

mskn08.transtelecom.net (87.229.217.102) 58.391 ms 64.492 ms

8 * * *

9 hll-gw.transtelecom.net (188.43.15.237) 66.761 ms 58.147 ms 63.482 ms

10 * * *

11 * * *

12 * * *

13 * * *

14 * * *

15 * * *

16 * * *

17 * * *

^C

 

 

wget eldorado.ru

--2016-07-14 23:03:42-- http://eldorado.ru/

Resolving eldorado.ru... 178.248.235.20

Connecting to eldorado.ru|178.248.235.20|:80... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Location: http://www.eldorado.ru/ [following]

--2016-07-14 23:03:42-- http://www.eldorado.ru/

Resolving www.eldorado.ru... 178.248.235.20

Reusing existing connection to eldorado.ru:80.

HTTP request sent, awaiting response... ^C

 

 

 

SIBDOM.RU - открывается

 

ping sibdom.ru

PING sibdom.ru (95.172.129.148): 56 data bytes

64 bytes from 95.172.129.148: icmp_seq=0 ttl=59 time=2.309 ms

64 bytes from 95.172.129.148: icmp_seq=1 ttl=59 time=2.234 ms

^C

--- sibdom.ru ping statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 2.234/2.272/2.309/0.038 ms

 

traceroute to sibdom.ru (95.172.129.148), 64 hops max, 52 byte packets

1 192.168.0.1 (192.168.0.1) 0.860 ms 0.611 ms 0.726 ms

2 * * *

3 80-255-149-25.ranetka.ru (80.255.149.25) 1.589 ms 1.345 ms 1.453 ms

4 c76peer-core-2.ranetka.ru (80.255.150.114) 1.813 ms 1.658 ms 1.806 ms

5 systemprojectsx2.sibir-ix.ru (91.230.210.21) 1.744 ms 1.698 ms 1.784 ms

6 185.24.92.6 (185.24.92.6) 1.700 ms 1.693 ms 1.698 ms

7 * * *

8 * * *

9 * * *

10 * * *

11 *^C

 

wget sibdom.ru

--2016-07-14 23:08:00-- http://sibdom.ru/

Resolving sibdom.ru... 95.172.129.148

Connecting to sibdom.ru|95.172.129.148|:80... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Location: http://www.sibdom.ru/ [following]

--2016-07-14 23:08:00-- http://www.sibdom.ru/

Resolving www.sibdom.ru... 95.172.129.148

Reusing existing connection to sibdom.ru:80.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [text/html]

Saving to: `index.html'

 

[ <=> ] 66,320 --.-K/s in 0.005s

 

2016-07-14 23:08:00 (13.1 MB/s) - `index.html' saved [66320]

 

 

 

SKYSCRAPERCITY.COM - не открывается:

 

ping skyscrapercity.com

PING skyscrapercity.com (66.249.131.2): 56 data bytes

Request timeout for icmp_seq 0

Request timeout for icmp_seq 1

Request timeout for icmp_seq 2

^C

 

traceroute skyscrapercity.com

traceroute to skyscrapercity.com (66.249.131.2), 64 hops max, 52 byte packets

1 192.168.0.1 (192.168.0.1) 0.891 ms 0.636 ms 0.676 ms

2 * * *

3 80-255-149-25.ranetka.ru (80.255.149.25) 2.032 ms 2.916 ms 1.911 ms

4 c76ext-core-2.ranetka.ru (80.255.150.116) 3.302 ms 2.531 ms 2.527 ms

5 195.239.180.97 (195.239.180.97) 2.901 ms 2.836 ms 3.422 ms

6 mx01.amsterdam.gldn.net (79.104.225.146) 100.872 ms

mx01.amsterdam.gldn.net (79.104.225.148) 98.356 ms

mx01.amsterdam.gldn.net (79.104.225.146) 102.054 ms

7 30gigabitethernet1-3.core1.ams1.he.net (80.249.209.150) 103.180 ms 104.428 ms 99.246 ms

8 100ge9-1.core1.lon2.he.net (72.52.92.213) 122.166 ms 128.962 ms 150.370 ms

9 100ge1-1.core1.nyc4.he.net (72.52.92.166) 183.581 ms

100ge8-2.core1.ash1.he.net (184.105.213.173) 200.956 ms 189.945 ms

10 100ge13-1.core1.lax1.he.net (184.105.80.202) 250.224 ms 248.991 ms 261.781 ms

11 100ge11-1.core1.lax2.he.net (72.52.92.122) 253.624 ms 253.466 ms 258.663 ms

12 corporate-colocation-inc.gigabitethernet2-19.core1.lax2.he.net (184.105.140.162) 249.161 ms 338.919 ms 266.143 ms

13 74.124.220.158 (74.124.220.158) 307.549 ms 322.026 ms 329.580 ms

14 66.117.11.186 (66.117.11.186) 327.914 ms 325.463 ms 259.249 ms

15 * * *

16 * * *

17 * * *

18 * * *

19 * * *

^C

 

 

wget skyscrapercity.com

--2016-07-14 23:12:52-- http://skyscrapercity.com/

Resolving skyscrapercity.com... 66.249.131.2

Connecting to skyscrapercity.com|66.249.131.2|:80... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Location: http://www.skyscrapercity.com/ [following]

--2016-07-14 23:12:52-- http://www.skyscrapercity.com/

Resolving www.skyscrapercity.com... 66.249.131.2

Reusing existing connection to skyscrapercity.com:80.

HTTP request sent, awaiting response... ^C

 

 

OPTIBIT.RU - открывается

 

ping optibit.ru

PING optibit.ru (185.25.60.66): 56 data bytes

64 bytes from 185.25.60.66: icmp_seq=0 ttl=58 time=2.783 ms

64 bytes from 185.25.60.66: icmp_seq=1 ttl=58 time=2.501 ms

64 bytes from 185.25.60.66: icmp_seq=2 ttl=58 time=2.699 ms

^C

--- optibit.ru ping statistics ---

3 packets transmitted, 3 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 2.501/2.661/2.783/0.118 ms

 

traceroute optibit.ru

traceroute to optibit.ru (185.25.60.66), 64 hops max, 52 byte packets

1 192.168.0.1 (192.168.0.1) 0.918 ms 0.640 ms 0.696 ms

2 * * *

3 80-255-149-25.ranetka.ru (80.255.149.25) 2.567 ms 3.053 ms 2.763 ms

4 c76peer-core-2.ranetka.ru (80.255.150.114) 2.961 ms 2.975 ms 2.684 ms

5 optizone-gw.sibir-ix.ru (91.230.210.46) 2.842 ms 3.185 ms 2.549 ms

6 c7600-tun40.optibit.ru (185.25.62.238) 2.636 ms 3.627 ms 2.295 ms

7 www.optibit.ru (185.25.60.66) 3.165 ms 4.026 ms 2.644 ms

 

wget optibit.ru --no-check-certificate

--2016-07-14 23:17:18-- http://optibit.ru/

Resolving optibit.ru... 185.25.60.66

Connecting to optibit.ru|185.25.60.66|:80... connected.

HTTP request sent, awaiting response... 302 Moved Temporarily

Location: https://www.optibit.ru/ [following]

--2016-07-14 23:17:18-- https://www.optibit.ru/

Resolving www.optibit.ru... 185.25.60.66

Connecting to www.optibit.ru|185.25.60.66|:443... connected.

WARNING: cannot verify www.optibit.ru's certificate, issued by `/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3':

Unable to locally verify the issuer's authority.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [text/html]

Saving to: `index.html.1'

 

[ <=> ] 59,081 --.-K/s in 0.008s

 

2016-07-14 23:17:18 (7.37 MB/s) - `index.html.1' saved [59081]

 

lk.beeline.ru - не открывается:

 

ping lk.beeline.ru

PING lk.beeline.ru (85.21.78.93): 56 data bytes

64 bytes from 85.21.78.93: icmp_seq=0 ttl=53 time=64.881 ms

64 bytes from 85.21.78.93: icmp_seq=1 ttl=53 time=64.952 ms

64 bytes from 85.21.78.93: icmp_seq=2 ttl=53 time=67.444 ms

^C

--- lk.beeline.ru ping statistics ---

3 packets transmitted, 3 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 64.881/65.759/67.444/1.192 ms

 

traceroute lk.beeline.ru

traceroute to lk.beeline.ru (85.21.78.93), 64 hops max, 52 byte packets

1 192.168.0.1 (192.168.0.1) 0.862 ms 0.662 ms 0.708 ms

2 * * *

3 80-255-149-25.ranetka.ru (80.255.149.25) 3.051 ms 3.705 ms 2.533 ms

4 c76ext-core-2.ranetka.ru (80.255.150.116) 2.313 ms 2.583 ms 1.816 ms

5 195.239.180.97 (195.239.180.97) 3.733 ms 2.870 ms 3.141 ms

6 pe03.kk12.moscow.gldn.net (79.104.235.215) 61.850 ms

pe03.kk12.moscow.gldn.net (79.104.235.213) 66.395 ms

pe03.kk12.moscow.gldn.net (79.104.235.215) 59.596 ms

7 gldn-gw-hq-bb.msk.corbina.net (195.14.41.5) 68.579 ms 69.433 ms 58.935 ms

8 mo-crs-be2.corbina.net (195.14.54.252) 64.140 ms 61.694 ms 72.284 ms

9 m9-crs-be3.corbina.net (195.14.54.141) 72.095 ms 66.332 ms 59.149 ms

10 rti-bb-be2.corbina.net (195.14.54.53) 60.210 ms 63.020 ms 63.499 ms

11 rti-iptv-bb-be3.corbina.net (78.107.184.53) 60.760 ms 59.645 ms 62.491 ms

12 8m-iptv-bb-vl23.corbina.net (85.21.226.75) 86.990 ms 59.261 ms 63.214 ms

13 * * *

14 * * *

15 * * *

16 * * *

17 * *^C

 

 

wget lk.beeline.ru

--2016-07-14 23:21:44-- http://lk.beeline.ru/

Resolving lk.beeline.ru... 85.21.78.93

Connecting to lk.beeline.ru|85.21.78.93|:80... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Location: https://lk.beeline.ru/ [following]

--2016-07-14 23:21:44-- https://lk.beeline.ru/

Connecting to lk.beeline.ru|85.21.78.93|:443... connected.

^C

 

 

ADMKRSK.RU - открывается:

 

ping admkrsk.ru

PING admkrsk.ru (95.170.190.147): 56 data bytes

64 bytes from 95.170.190.147: icmp_seq=0 ttl=122 time=3.203 ms

64 bytes from 95.170.190.147: icmp_seq=1 ttl=122 time=3.289 ms

64 bytes from 95.170.190.147: icmp_seq=2 ttl=122 time=2.606 ms

^C

--- admkrsk.ru ping statistics ---

3 packets transmitted, 3 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 2.606/3.033/3.289/0.304 ms

 

traceroute admkrsk.ru

traceroute to admkrsk.ru (95.170.190.147), 64 hops max, 52 byte packets

1 192.168.0.1 (192.168.0.1) 1.399 ms 2.144 ms 0.884 ms

2 * * *

3 80-255-149-25.ranetka.ru (80.255.149.25) 4.161 ms 1.391 ms 1.438 ms

4 c76peer-core-2.ranetka.ru (80.255.150.114) 2.096 ms 1.606 ms 1.502 ms

5 krosline-gw.krs-ix.ru (217.117.187.4) 1.673 ms 1.893 ms 2.202 ms

6 gw-vl200.multi-net.ru (89.105.149.60) 2.136 ms 3.026 ms 2.419 ms

7 95.170.190.190 (95.170.190.190) 5.221 ms 2.451 ms 2.307 ms

8 * * *

9 * * *

10 * * *

11 *^C

 

wget admkrsk.ru

--2016-07-14 23:25:20-- http://admkrsk.ru/

Resolving admkrsk.ru... 95.170.190.147

Connecting to admkrsk.ru|95.170.190.147|:80... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Location: http://www.admkrsk.ru/ [following]

--2016-07-14 23:25:21-- http://www.admkrsk.ru/

Resolving www.admkrsk.ru... 95.170.190.152

Connecting to www.admkrsk.ru|95.170.190.152|:80... connected.

HTTP request sent, awaiting response... 302 Redirect

Location: http://www.admkrsk.r...es/default.aspx [following]

--2016-07-14 23:25:21-- http://www.admkrsk.r...es/default.aspx

Reusing existing connection to www.admkrsk.ru:80.

HTTP request sent, awaiting response... 200 OK

Length: 118423 (116K) [text/html]

Saving to: `default.aspx'

 

100%[==========================================================>] 118,423 --.-K/s in 0.05s

 

2016-07-14 23:25:22 (2.43 MB/s) - `default.aspx' saved [118423/118423]

 

 

MVIDEO.RU - что интересно, тоже открывается. Обратите внимание на *отсутствие* в его маршруте хопа c76ext-core-2.ranetka.ru (80.255.150.116)

 

traceroute to mvideo.ru (91.220.181.5), 64 hops max, 52 byte packets

1 192.168.0.1 (192.168.0.1) 1.235 ms 0.779 ms 0.802 ms

2 * * *

3 80-255-149-25.ranetka.ru (80.255.149.25) 4.172 ms 1.357 ms 1.391 ms

4 80-255-128-102.ranetka.ru (80.255.128.102) 1.599 ms 1.497 ms 1.491 ms

5 195.239.180.97 (195.239.180.97) 2.442 ms 1.836 ms 2.371 ms

6 pe04.moscow.gldn.net (79.104.225.70) 61.786 ms

pe04.moscow.gldn.net (79.104.225.74) 58.994 ms

pe04.moscow.gldn.net (79.104.225.70) 60.431 ms

7 * * *

8 * * *

9 * * *

10 * * *

 

 

wget mvideo.ru

--2016-07-15 00:04:21-- http://mvideo.ru/

Resolving mvideo.ru... 91.220.181.5

Connecting to mvideo.ru|91.220.181.5|:80... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Cookie coming from mvideo.ru attempted to set domain to www.mvideo.ru

Location: http://www.mvideo.ru/ [following]

--2016-07-15 00:04:21-- http://www.mvideo.ru/

Resolving www.mvideo.ru... 91.220.181.5, 91.220.181.87

Reusing existing connection to mvideo.ru:80.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [text/html]

Saving to: `index.html.3'

 

[ <=> ] 392,902 666K/s in 0.6s

 

2016-07-15 00:04:22 (666 KB/s) - `index.html.3' saved [392902]

 

Изменено пользователем NikIv

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@mobilon

И снова нет того, что я просил - нет смены MAC-адреса.

Но почему я не удивлен...

И еще так и непонятно дор сих пор, какой тип подключения используется: PPTP или L2TP?

А также нет трасс при прямом подключении без роутера, чтобы найти отличие.

P.S. Эта ранетка - купленный Билайном местный провайдер?

Изменено пользователем _Slava_

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@mobilon

И снова нет того, что я просил - нет смены MAC-адреса.

Но почему я не удивлен...

И еще так и непонятно дор сих пор, какой тип подключения используется: PPTP или L2TP?

А также нет трасс при прямом подключении без роутера, чтобы найти отличие.

P.S. Эта ранетка - купленный Билайном местный провайдер?

 

А на какой поменять? Если просто изменить какой нибудь из октетов на единицу - подойдет?

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

С макбуком и айфоном прямое подключение организовать несколько проблематично - нет ethernet порта.

Мне для этого надо везти домой компьютер на Windows, что вчера ночью было сделать сложно.

Подключение - L2TP.

Да, ранетка раньше был самостоятельным провайдером, назывался "Сибчеллендж"

Изменено пользователем mobilon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нет, нужно взять MAC-адрес с компьютера, использовавшегося ранее без проблем:

Если подключить кабель напрямую к компьютеру и установить VPN-подключение к Билайн с него - то все открывается.

На роутере тоже L2TP?

Изменено пользователем _Slava_

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Есть кстати ещё один вариант: твою wi-fi поломали, и врезались между тобой и роутером. Либо получили доступ а админке роутера из вне.

Это объясняет непостоянство проблемы, отсутствие массовых жалоб и то что у тебя всё работает кроме http(причём частично).

Изменено пользователем MoonFire

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Есть кстати ещё один вариант: твою wi-fi поломали, и врезались между тобой и роутером. Либо получили доступ а админке роутера из вне.

Это объясняет непостоянство проблемы, отсутствие массовых жалоб и то что у тебя всё работает кроме http(причём частично).

 

А как возможный взлом объясняет это - маршруты до всех сайтов, которые открываются, имеют 4й хоп c76peer-core-2.ranetka.ru (80.255.150.114). А маршруты до сайтов, которые не открываются имеют 4й хоп c76ext-core-2.ranetka.ru (80.255.150.116)?

 

Нет, нужно взять MAC-адрес с компьютера, использовавшегося ранее без проблем:

Если подключить кабель напрямую к компьютеру и установить VPN-подключение к Билайн с него - то все открывается.

На роутере тоже L2TP?

 

Да, на роутере L2TP

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@MoonFire

Описанный Вами сценарий не вписывается в результаты тестов.

 

@mobilon,

https тоже не работает при таких проблемах?

Изменено пользователем _Slava_

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А как возможный взлом объясняет это - маршруты до всех сайтов, которые открываются, имеют 4й хоп c76peer-core-2.ranetka.ru (80.255.150.114). А маршруты до сайтов, которые не открываются имеют 4й хоп c76ext-core-2.ranetka.ru (80.255.150.116)?

К примеру домыслы.

 

@MoonFireОписанный Вами сценарий не вписывается в результаты тестов.

ARP-spoofing + fake http proxy. В каком месте он не вписывается?

 

Есть кстати ещё один вариант: твою wi-fi поломали, и врезались между тобой и роутером. Либо получили доступ а админке роутера из вне.Это объясняет непостоянство проблемы, отсутствие массовых жалоб и то что у тебя всё работает кроме http(причём частично).
А как возможный взлом объясняет это - маршруты до всех сайтов, которые открываются, имеют 4й хоп c76peer-core-2.ranetka.ru (80.255.150.114). А маршруты до сайтов, которые не открываются имеют 4й хоп c76ext-core-2.ranetka.ru (80.255.150.116)?

Какая связь между этим и тем что напрямую всё работает? Пакеты без роутера по другому маршруту идут?

 

Я не утверждаю на 100%, но пароли поменять на рекомендую. А заодно посмотреть логи на роутере если есть

Изменено пользователем MoonFire

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@MoonFire

Описанный Вами сценарий не вписывается в результаты тестов.

 

@mobilon,

https тоже не работает при таких проблемах?

 

Да, https тоже, если сайт не в пиринге. Если в пиринге - то все ок

 

А как возможный взлом объясняет это - маршруты до всех сайтов, которые открываются, имеют 4й хоп c76peer-core-2.ranetka.ru (80.255.150.114). А маршруты до сайтов, которые не открываются имеют 4й хоп c76ext-core-2.ranetka.ru (80.255.150.116)?

К примеру домыслы.

 

@MoonFireОписанный Вами сценарий не вписывается в результаты тестов.

ARP-spoofing + fake http proxy. В каком месте он не вписывается?

 

Есть кстати ещё один вариант: твою wi-fi поломали, и врезались между тобой и роутером. Либо получили доступ а админке роутера из вне.Это объясняет непостоянство проблемы, отсутствие массовых жалоб и то что у тебя всё работает кроме http(причём частично).
А как возможный взлом объясняет это - маршруты до всех сайтов, которые открываются, имеют 4й хоп c76peer-core-2.ranetka.ru (80.255.150.114). А маршруты до сайтов, которые не открываются имеют 4й хоп c76ext-core-2.ranetka.ru (80.255.150.116)?

Какая связь между этим и тем что напрямую всё работает? Пакеты без роутера по другому маршруту идут?

 

Я не утверждаю на 100%, но пароли поменять на рекомендую. А заодно посмотреть логи на роутере если есть

 

Какие домыслы? Я это совершенно точно установил - я же выкладывал уже здесь (http://homenet.beeline.ru/index.php?showtopic=323478&view=findpost&p=1065258861) штук 10 трейсов до разных сайтов, про которые точно известны, в пиринге они или нет.

 

Без роутера пока нет возможности попробовать, но сомневаюсь, что маршрут будет другим, т.к. даже по доменным именам хопов понятно, что тот, который c76peer - это для пиринговых сайтов, а c76ext - для остальных.

Пароль на wi-fi сменю на всякий случай.

 

В логах роутера есть вот такие строчки:

78 Jul 16 19:01:39 DHCP ИНФО DHCPC: get 3 static route from Microsoft classless static route option(249)

77 Jul 16 19:01:39 DHCP ИНФО DHCPC: get 2 static route from classless static route option(121)

 

Я так понимаю, что dhcp выдает 3 статических маршрута для клиентов под Windows и 2 маршрута для rfc-клиентов, в том числе роутеров? Не здесь ли кроется причина этой проблемы? Может быть маршруты некорректные? Или rfc-клиентам выдается неполный набор маршрутов?

 

Нет, нужно взять MAC-адрес с компьютера, использовавшегося ранее без проблем

 

Мак поменял и после перезагрузки роутера все заработало. Интересно, надолго ли?)

Изменено пользователем mobilon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас