конецформыначалоформыПротокол обмена между Skype-клиентами совершенно недокументирован, и поэтому вся информация о нем получена методами реинженеринга: дизассемблирования Skype-клиентов, анализа перехваченного сетевого трафика и т.д. Поскольку существует огромное количество значительно различающихся между собой версий Skype-клиентов, то описание протокола может содержать неточности, во всяком случае, open-source-клиента еще никто не написал.
Сразу же после своего запуска Skype-клиент открывает TCP- и UDP-порты. Их номера случайным образом задаются при инсталляции и могут быть в любой момент изменены через диалог конфигурации, что затрудняет блокирование Skype-трафика на брандмауэре. Помимо этого, Skype открывает порты 80 (HTTP) и 443, однако они не являются жизненно важными, и, даже если их заблокировать, Skype ничуть не огорчится.
Ситуация осложняется тем, что Skype шифрует трафик, активно используя продвинутые технологии обфускации, препятствующие выделению постоянных сигнатур в полях заголовков. Алгоритмы шифрования меняются от версии к версии, к тому же выпущено множество специальных версий для разных стран мира, чьи законы налагают определенные ограничения на длину ключа или выбранные криптографические алгоритмы. Но в целом механизм шифрования выглядит так, как показано на рисунке.
Skype-клиенты крайне деликатно обходятся с брандмауэрами и трансляторами сетевых адресов, просачиваясь сквозь них через хорошо известные протоколы STUN и TURN. Протокол STUN уже вошел в Библию Интернета и подробно описан в RFC-3489
Так что, с юридической точки зрения, действия Skype законны и не попадают под статью. STUN, расшифровывающийся как Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (простое проникновение датаграмм протокола UDP через транслятор сетевых адресов (NAT)), представляет собой отличное средство, которое страдает, однако, рядом ограничений и не работает в следующих случаях:
если путь во внешнюю сеть прегражден злобным брандмауэром, режущим весь UDP;
если на пути во внешнюю сеть стоит симметричный транслятор сетевых адресов.
Ну, с брандмауэром все понятно. Если UDP закрыт, то никак его не откроешь. А вот симметричный транслятор сетевых адресов (symmetric NAT) — это что за штука? Не углубляясь в технические детали, скажем, что симметричный NAT представляет собой разновидность обыкновенного транслятора, требующего, чтобы целевой IP-адрес и порт транслируемого пакета совпадали с внешним (external) IP-адресом и портом. Если один и тот же узел посылает пакеты с одинаковыми исходными IP-адресами и портами по разным направлениям, NAT будет вынужден транслировать их на другие порты. Таким образом, чтобы отправить внутреннему узлу UDP-пакет, внешний узел должен первым делом получить запрос от внутреннего узла. Самостоятельно инициировать соединение внешний узел не в состоянии, поскольку NAT просто не знает, на какой внутренний IP и порт следует транслировать неожиданно сваливавшийся UDP-пакет.
Эта проблема решается протоколом TURN (Traversal Using Relay NAT), технические подробности работы которого описаны по вышеупомянутому адресу и большинству читателей совершенно неинтересны. Гораздо важнее другое — протокол TURN значительно увеличивает латентность и теряет большое количество UDP-пакетов (packet loss), что далеко не лучшим образом сказывается на качестве и устойчивости связи, но полное отсутствие связи — еще хуже. Так что пользователям Skype стоит радоваться, а не жаловаться!
Вот только администраторы этой радости почему-то не разделяют, наглухо закрывая UDP-трафик (тем более что большинству нормальных программ он не нужен). Немного поворчав для приличия (замуровали, демоны!), Skype автоматически переключается на чистый TCP, отрубить который администратору никто не позволит. Правда, поколдовав над брандмауэром, тот может закрыть все неиспользуемые порты, но в том-то и подвох, что неиспользуемых портов в природе не встречается! При соединении с удаленным узлом операционная система назначает клиенту любой свободный TCP/UDP-порт, на который будут приходить пакеты. То есть, если мы подключаемся к web-серверу по 80-му порту, наш локальный порт может оказаться 1369-м, 6927-м или еще каким-нибудь другим. Закрыв все порты, мы лишимся возможности устанавливать TCP/UDP-соединения!
Единственный выход — обрубить всем пользователям локальной сети прямой доступ в интернет, заставив их ходить через proxy-сервер. Однако даже такие драконовские меры не решат проблемы, поскольку Skype просто прочитает конфигурацию браузера и воспользуется proxy-сервером как своим родным!