Добрый вечер, уважаемые форумчане. Сразу оговорюсь, что я не сисадмин, но так уж получилось, что наш сисадмин отрицает очевидную проблему. Суть в чем: у пользователей с выданным серым IP наблюдаются проблемы со скайпом: звонки длятся по 10 секунд, затем сбрасываются, при попытке поднять трубку сброс происходит сразу. По итогу звонка выдается сообщение "звонок прерван". Если бордер выдал белый IP проблем вообще никаких. Не уверен, что это связано, но в онлайн играх наблюдаются фризы и дропы пакетов при сером IP, при белом - проблем нет. Конфиг скинуть не могу ибо доступа не имею, но может кто-то подскажет куда копать? Есть дампы вайршарка, но сисадмин в них проблем не увидел и просто порекомендовал отказаться от скайпа, а так уж сложилась ситуация в регионе (Донбасс), что у людей это единственное средство коммуникации с родными и треть абонбазы пользуется интернетом только из-за скайпа. Заранее благодарю за помощь.

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

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


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

Конфигурацию NAT покажите пожалуйста.

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


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

чет с timeoutами перемудрили явно.

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


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

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

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


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

Столкнулись с такой же проблемой. Каким образом вам удалось её решить?

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


Ссылка на сообщение
Поделиться на другие сайты
48 минут назад, ARTIsshoque сказал:

Столкнулись с такой же проблемой. Каким образом вам удалось её решить?

Разобрались.

В нат полиси не хватало строк:

 

   

    admission-control tcp
    admission-control udp
    admission-control icmp
    endpoint-independent filtering tcp
    endpoint-independent filtering udp

 

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


Ссылка на сообщение
Поделиться на другие сайты
8 минут назад, ARTIsshoque сказал:

Разобрались.

В нат полиси не хватало строк:

 

   


    admission-control tcp
    admission-control udp
    admission-control icmp
    endpoint-independent filtering tcp
    endpoint-independent filtering udp

 

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

больше интересен момент с redistribute nat. как правильно его описать?

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


Ссылка на сообщение
Поделиться на другие сайты
3 часа назад, casper.w00t сказал:

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

больше интересен момент с redistribute nat. как правильно его описать?

У нас нет redistribute nat. SE отправляет абонентский трафик на бордер с BGP.

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


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

Если меня не подводит память:

Skype особенен тем, что делает исходящее соединение на специальный сервер, который определяет IP/порт куда его с'NAT'или. Далее эти параметры сообщаются той стороне которая собирается звонить - и идет входящее соединение на IP/порт, но не с того адреса, на который было исходящее соединение. 

Те NAT которые такой шутки не ожидают не принимают входящее соединение. Из-за несоответствия того что было при инициации соединения тому что прилетело следом.

Нам пришлось включать какую-то опцию на SE100. Некоторые реализации возможно содержат опции инспекции протокола Skype.

Ранее трафик шел через транзитные сервера в случае NAT но Микрософт решил уйти от этого элемента и организовать прямую связь через финт ушами.

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


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

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

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

 

 

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


Ссылка на сообщение
Поделиться на другие сайты
14 часов назад, Tosha сказал:

Если меня не подводит память:

Skype особенен тем, что делает исходящее соединение на специальный сервер, который определяет IP/порт куда его с'NAT'или. Далее эти параметры сообщаются той стороне которая собирается звонить - и идет входящее соединение на IP/порт, но не с того адреса, на который было исходящее соединение. 

Те NAT которые такой шутки не ожидают не принимают входящее соединение. Из-за несоответствия того что было при инициации соединения тому что прилетело следом.

Нам пришлось включать какую-то опцию на SE100. Некоторые реализации возможно содержат опции инспекции протокола Skype.

Ранее трафик шел через транзитные сервера в случае NAT но Микрософт решил уйти от этого элемента и организовать прямую связь через финт ушами.

Хм... они просто вернулись к истокам. Изначально "фишка" скайпа была в том, что он работал типа как p2p, т.е. трафик по возможности гонялся напрямую между абонентами. Потом от этого избавилялись(https://arstechnica.com/information-technology/2016/07/skype-finalizes-its-move-to-the-cloud-ignores-the-elephant-in-the-room/ ) и трафик гонялся через узлы skype, теперь вот опять они решили децентрализовать коммуникации (судя по этому топику, каких-то пруфов этому не находится быстро), что странно и не в духе проприетарного ПО, следящего за своими пользователями

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


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

Точнее история выглядела так:

Skype сделал сеть  P2P и узлы с реальными IP имели режим транзитного сервера. Клиенты из-под NAT соединялись через назначенный им транзитный узел. То есть местами получалась P2P2P сеть.

Микрософт выпилил режим сервера из оконечных клиентов и сделал свои сервера.

Микрософт ушел от серверов сделав сеть истинно P2P и для тех кто за NAT. Но если не повезет админам NAT серверов придется "чинить".

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


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

Для публикации сообщений создайте учётную запись или авторизуйтесь

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

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти