История изменений

Исправление AS, 04.11.19 09:29 (текущая версия) :

я вопрос то закинул для того чтоб узнать может есть какие инструменты на каком хопе допустим это происхоит?

Нет к сожалению. Причём промежуточный маршрутизатор вовсе может на запросы к себе любимому не отвечать, либо отвечать через раз и т.п. - его дело транзит обеспечить. А уж тем более что-то про порты. В лучшем случае, если там действительно фильтр, destination port unreachable может придти, но может быть настроен и просто дроп. Причём telnet-сессия не висела бы в этом случае, если бы port unreachable возвращался бы, так что у тебя точно не этот случай.

мне присоветовали утилиту WINMTR она определяет хопы и пингует их по очереди, определяя на каком хопе начинаются проблемы, тогда я понимаю какого провайдера надо трясти

Тут, кстати, тоже не всё однозначно. Например, если у тебя есть хоп с потерями, а за ним дальше всё хорошо, то этот хоп к делу не относится. Либо если есть асимметрия, а она всегда обычно есть, то реальная проблема может оказаться на обратном маршруте совсем у другого провайдера. Как-то статейка попалась на хабре: https://habr.com/en/post/129627/

Исходная версия AS, 04.11.19 09:28:

я вопрос то закинул для того чтоб узнать может есть какие инструменты на каком хопе допустим это происхоит?

Нет к сожалению. Причём промежуточный маршрутизатор вовсе может на запросы к себе любимому не отвечать, либо отвечать через раз и т.п. - эго дело транзит обеспечить. А уж тем более что-то про порты. В лучшем случае, если там действительно фильтр, destination port unreachable может придти, но может быть настроен и просто дроп. Причём telnet-сессия не висела бы в этом случае, если бы port unreachable возвращался бы, так что у тебя точно не этот случай.

мне присоветовали утилиту WINMTR она определяет хопы и пингует их по очереди, определяя на каком хопе начинаются проблемы, тогда я понимаю какого провайдера надо трясти