Намучался с этим скайпом из-под Squid 3.48, аналогично так же мучался и во время использования TMG.
То звонки не проходили, то сообщения, а то он тупо крутил значок при запуске, не авторизуясь.
Сниффером смотрел, куда он лезет, оказалось - почти куда угодно, кроме прокси. Создалось впечатление, что на системные настройки прокси в IE ему вообще плевать, даже если в его настройках жестко ставишь прокси и прописываешь его имя и порт.
Оказалось, что для Скайпа существует в природе административный шаблон GPO, доступен он по адресу
http://download.skype.com/share/security/Skype-v1.7.adm. Поэкспериментировал и создал политику пользователя с параметрами:
Skype/Phone/Network
Proxy type HTTPS
Proxy address (host:port) group-s-squid.domain.ru:3128
На удивление, Скайп тут же авторизовался и позеленел, сообщения стали отправляться и получаться, звонки - звониться и приниматься:)
Но это еще не конец истории. Хоть убей не пойму как, но звонки почему-то ходили только среди абонентов нашей локальной сети, заметили это не сразу. Почему - абсолютно непонятно, Скайп по идее для вызова в любом случае выходит в инет, а какая тогда разница, кому направляется звонок? Но все вызовы "наружу" проходили так: идет набор абонента, в колонках полная тишина, на 12-й секунде звонок автоматом завершается.
Полез в логи сквида, и обнаружил множество записей обращения к доменам в инете со статусом "denied", естественно запросы шли неавторизованные, и сквид с доменной авторизацией пропускать их не хотел. Пришлось лепить список исключений, на которые можно посылать неавторизованные запросы, который грубо сейчас выглядит примерно так:
.skype.com
.msecnd.net
.windows.net
.trouter.io
.adnxs.com
.skypeassets.com
.aspnetcdn.com
.serving-sys.com
.taboola.com
.microsofttranslator.com
.msads.net
.microsoftonline.com
.lync.com
.globalsign.com
Понимаю, что сейчас открыто слишком много, и поэтому список надо допиливать более тонко, одних субдоменов skype.com несколько штук было. Просто нужно было срочно дать людям возможность звонить, т.к. кадровики по скайпу проводят собеседования.
Но и этого списка оказалось мало. Полазив по инету, нашел не очень свежую инструкцию Микрософта
https://support.office.com/en-us/articl ... S&fromAR=1 по настройке сетевого соединения, где указаны домены и IP адреса. Поэкспериментировал с добавлением сетей, которые там приведены (не всех!). В итоге получился такой acl, при котором все стало работать как надо:
acl skypenet dst 40.127.0.0/16
acl skypenet dst 13.107.8.0/24
acl skypenet dst 157.55.0.0/16
acl skypenet dst 91.190.217.0/24
acl skypenet dst 91.190.216.0/24
acl skypenet dst 40.79.44.0/24
acl skypenet dst 104.44.200.0/23
acl skypenet dst 104.40.75.8/32
acl skypenet dst 104.40.76.196/32
acl skypenet dst 104.40.91.215/32
acl skypenet dst 104.41.207.112/32
acl skypenet dst 104.41.210.140/32
acl skypenet dst 104.42.229.230/32
acl skypenet dst 104.43.12.164/32
acl skypenet dst 104.44.195.0/24
acl skypenet dst 104.45.231.95/32
acl skypenet dst 104.46.96.162/32
acl skypenet dst 104.46.97.194/32
acl skypenet dst 104.46.101.116/32
acl skypenet dst 104.46.105.95/32
acl skypenet dst 104.208.28.54/32
acl skypenet dst 104.208.31.113/32
acl skypenet dst 104.208.152.137/32
acl skypenet dst 104.210.1.218/32
acl skypenet dst 104.210.80.193/32
acl skypenet dst 104.211.162.59/32
acl skypenet dst 104.211.165.113/32
acl skypenet dst 104.211.165.216/32
Ну и правило:
http_access allow skypenet localnet
Теперь как-то все это надо причесать и по возможности уменьшить списки.
Почему вдруг так ужасно скайп стал работать - мне лично неведомо. Единственная мысль - может, корпоративных пользователей пытаются пересадить на Lync, заставляя новые версии скайпа некорректно работать с прокси (даже с TMG были проблемы!)