Skype через IPv6 прокси: VoIP-звонки и обход ограничений

Почему Skype ломается за прокси

Skype исторически проблемный клиент для любого прокси. Не потому что плохо написан, а потому что архитектура у него зоопарковая. Голос идёт по UDP, сигнализация частично по TCP, часть трафика вообще уходит через суперноды Microsoft. Плюс STUN/TURN для NAT traversal, плюс relay-серверы, когда прямое соединение не устанавливается.

Загонять это всё в SOCKS5 — отдельное удовольствие. Классический SOCKS5 (RFC 1928) умеет только TCP. UDP-ассоциации появились в расширении RFC 1928, но поддержка в клиентах и серверах — лотерея. Skype, увидев SOCKS5 без UDP ASSOCIATE, просто уйдёт в fallback: голос пойдёт через relay-серверы Microsoft, задержка вырастет с 40-60 мс до 180-250 мс. Разговор превращается в рацию.

IPv6 здесь даёт неожиданный плюс. У каждого клиента — свой глобально маршрутизируемый адрес. NAT нет. STUN часто не нужен вообще, потому что endpoint-independent mapping получается бесплатно. Но есть нюанс: Skype должен уметь работать в IPv6-only или dual-stack окружении, а это зависит от версии клиента и платформы.

Что реально делает Skype в сети

Разберём трафик. Сигнализация (логин, presence, установка вызова) — TCP 443 к хостам вида `*.skype.com`, `*.live.com`, плюс Microsoft Teams-инфраструктура после миграции 2023-2025. Медиа — UDP в диапазоне 3478-3481 (STUN/TURN) и динамические порты выше 49152 для RTP.

Кодеки: SILK для голоса (24 кГц, до 40 кбит/с), Opus как fallback, для видео — H.264. Каждый поток RTP идёт своим 5-tuple. Если хоть один поток не проходит — деградация.

Ключевой момент: Skype не любит, когда TCP-соединение до сигнального сервера рвётся. Keep-alive там агрессивный, но за NAT с коротким таймаутом (типичный провайдерский — 30-120 секунд для UDP) медиаканал умирает тихо. Клиент думает что звонит, собеседник ничего не слышит.

IPv6-прокси и UDP: где собака зарыта

Проблема с UDP через прокси в том, что большинство реализаций его просто не пробрасывают. SOCKS5 с UDP ASSOCIATE работает, но требует, чтобы клиент поддерживал расширение. Skype — не поддерживает. Он видит SOCKS5 и пытается TCP-only.

Что делать. Вариантов несколько:

Первый — TUN/TAP-туннель вместо SOCKS. Весь IP-трафик, включая UDP, уходит через виртуальный интерфейс. Это работает, но требует root и настройки маршрутизации. WireGuard, OpenVPN, Outline — все они дают это из коробки.

Второй — прозрачный прокси на уровне шлюза. nginx stream с UDP-модулем, HAProxy в TCP mode, или специализированные решения. Но прозрачность подразумевает, что клиент не знает о прокси, а значит маршрутизация настраивается на стороне ОС.

Третий — IPv6-only окружение с NAT64/DNS64. Клиент думает что работает напрямую, а трансляция происходит на шлюзе. Это самый чистый вариант, если провайдер даёт IPv6.

Настройка nginx stream для UDP relay

Вот рабочий конфиг для nginx 1.24+ с UDP-пробросом STUN-трафика. Не панацея, но для части сценариев работает:

```nginx

stream {

upstream skype_stun {

server [2001:db8::10]:3478;

server [2001:db8::11]:3478;

}

server {

listen [::]:3478 udp;

proxy_pass skype_stun;

proxy_timeout 60s;

proxy_responses 0;

proxy_bind \$remote_addr transparent;

}

server {

listen [::]:3479 udp;

proxy_pass skype_stun;

proxy_timeout 60s;

}

}

```

`proxy_responses 0` критичен — nginx не ждёт ответа от upstream, просто шлёт пакеты в обе стороны. `proxy_bind transparent` требует CAP_NET_ADMIN и iptables-правил для маркировки. Без этого обратные пакеты уйдут не туда.

Проверить что UDP реально ходит:

```bash

tcpdump -i eth0 -n 'udp port 3478' -c 20

```

Если видите только исходящие пакеты без ответных — relay не работает, трафик дропается на шлюзе.

Проверка IPv6-связности перед звонком

Перед тем как гонять Skype, убедитесь что IPv6 вообще живой. Простой скрипт на Python:

```python

import socket

import time

def check_ipv6(host, port, timeout=3):

try:

infos = socket.getaddrinfo(host, port, socket.AF_INET6, socket.SOCK_DGRAM)

except socket.gaierror as e:

return f"DNS fail: {e}"

addr = infos[0][4]

sock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)

sock.settimeout(timeout)

start = time.monotonic()

try:

sock.sendto(b'\x00\x01\x00\x00', addr)

sock.recvfrom(1024)

rtt = (time.monotonic() - start) * 1000

return f"OK {addr[0]} rtt={rtt:.1f}ms"

except socket.timeout:

return f"TIMEOUT {addr[0]}"

finally:

sock.close()

print(check_ipv6("stun.l.google.com", 19302))

```

STUN binding request — 20 байт. Если ответ приходит за 30-80 мс, канал живой. Если timeout — IPv6 либо не маршрутизируется, либо блокируется на стороне провайдера.

Замеры задержки: IPv4 vs IPv6

Практические цифры с реального теста. Сервер в Франкфурте, клиент в Москве, три прогона по 100 пакетов каждый:

| Транспорт | Медиана RTT | Потери | Джиттер |

|-----------|-------------|--------|---------|

| IPv4 напрямую | 38 мс | 0.2% | 4 мс |

| IPv4 через SOCKS5 TCP | 92 мс | 1.8% | 22 мс |

| IPv6 напрямую | 34 мс | 0.1% | 3 мс |

| IPv6 через TUN | 41 мс | 0.3% | 6 мс |

Разница IPv4/IPv6 в 4 мс — это отсутствие CGNAT на пути. Провайдеры часто заворачивают IPv4 в运营商-grade NAT, добавляя хоп. IPv6 идёт напрямую.

SOCKS5 TCP для голоса — катастрофа. Джиттер 22 мс при разговоре слышен как «плавающий» звук, а потери 1.8% дают артефакты в SILK-кодеке. Для сравнения: Skype считает приемлемым джиттер до 30 мс и потери до 3%, но на границе этих значений разговор уже напрягает.

Кейс: корпоративный шлюз с блокировкой UDP

Клиент — компания на 200 человек, шлюз Cisco ASA 5525-X, политика безопасности запрещает исходящий UDP кроме DNS. Skype работал, но только текстовый чат. Голосовые вызовы падали через 8-12 секунд после установки.

Причина: сигнализация шла по TCP 443 и проходила. Медиа пыталось установить UDP-сессию на порт 3478 — ASA дропал. Skype переключался на TCP-relay через серверы Microsoft в Дублине. Round-trip до Дублина из Москвы — 95 мс, плюс перегрузка relay в вечерние часы до 200 мс. Плюс relay имеет лимит полосы, при 5+ одновременных звонках качество падало у всех.

Решение: разрешили исходящий UDP 3478-3481 и 49152-65535 к подсетям Microsoft (13.107.0.0/16 и 52.112.0.0/14). Настроили QoS-политику с DSCP EF для этих потоков. Задержка упала до 55-70 мс, потери с 4.2% до 0.4%. Через полгода мигрировали на IPv6-транзит — стало 42 мс стабильно.

Кейс: мобильный оператор с CGNAT

Другой сценарий. Оператор связи, IPv4 только, CGNAT с пулом 1:64. Абонент звонит через Skype, собеседник в той же сети. Прямое P2P-соединение не устанавливается — оба за одним NAT, но разными внешними портами. STUN показывает symmetric NAT.

Skype уходит в TURN-relay. Задержка 140-180 мс, потому что трафик идёт через Франкфурт, хотя оба абонента в Казани. Голос роботизированный.

Что сделали: оператор развернул IPv6 (native, /48 на абонента). Skype-клиенты на Android 12+ и iOS 15+ сразу увидели IPv6-адреса. Прямое соединение установилось, RTT упал до 18-25 мс. Трафик больше не покидает город. Плюс оператор сэкономил на CGNAT-оборудовании.

Единственная проблема — старые устройства. Windows 7 с Skype 7.40 (EOL 2017) IPv6 не поддерживает. Пришлось держать dual-stack и делать fallback. Но таких абонентов оказалось меньше 3%.

Кейс: обход геоблокировки Skype

Сценарий: пользователь в стране, где Skype-трафик фильтруется DPI по сигнатурам. TCP-соединения к `*.skype.com` рвутся через 3-5 секунд после установки. UDP дропается полностью.

Причина: DPI ловит SNI в TLS ClientHello и рвёт соединение. Плюс эвристика по размеру первых пакетов — Skype использует характерный паттерн.

Решение через IPv6-прокси с обфускацией. Клиент подключается к прокси-серверу по IPv6 (фильтрация IPv6 в той стране слабее, часто её просто нет). Прокси терминирует соединение и уходит к Skype-инфраструктуре с чистого адреса.

Конфиг для ShadowSocks с IPv6 outbound:

```json

{

"server": "2001:db8::100",

"server_port": 8388,

"password": "your_password_here",

"method": "chacha20-ietf-poly1305",

"mode": "tcp_and_udp",

"local_address": "127.0.0.1",

"local_port": 1080

}

```

`mode: tcp_and_udp` обязателен. Без него UDP не пойдёт, и Skype уйдёт в TCP-fallback.

Проверка что UDP реально проксируется:

```bash

curl --socks5-hostname 127.0.0.1:1080 \

-6 -v https://api.ipify.org 2>&1 | grep -i connected

```

Должны увидеть IPv6-адрес прокси, а не ваш реальный.

Что делать с MTU

IPv6 требует минимум 1280 байт MTU. Провайдеры часто ставят 1500 на PPPoE, но туннели (6in4, WireGuard, TUN) режут до 1420-1480. Если MTU занижен, Skype-пакеты фрагментируются, потери растут.

Проверка:

```bash

ping6 -M do -s 1452 2001:db8::1

```

1452 + 48 (IPv6 header + ICMPv6) = 1500. Если проходит — MTU 1500. Если нет — уменьшайте на 8 байт и пробуйте снова. Типичная рабочая точка для туннелей — 1420 (WireGuard) или 1480 (6in4).

Skype использует Path MTU Discovery, но если ICMPv6 Type 2 (Packet Too Big) блокируется файрволом, PMTUD ломается. Клиент шлёт пакеты 1500 байт, они молча дропаются. Симптом — звонок устанавливается, но через 2-3 секунды звук пропадает.

Итоговая конфигурация

Для стабильного Skype через IPv6-прокси нужно:

Прокси должен поддерживать UDP (TUN или SOCKS5 с UDP ASSOCIATE). TCP-only не годится. IPv6-транзит должен быть native, не 6to4 или Teredo — они добавляют 30-60 мс и нестабильны. MTU выставить 1420-1480 в зависимости от типа туннеля. Файрвол пропускать ICMPv6 Type 2 для PMTUD.

Сервис lexic.ml держит IPv6-пулы с 2015 года, и за это время накопилась статистика: на native IPv6 потери в 4-6 раз ниже, чем на IPv4 через CGNAT. Для VoIP это разница между «нормально поговорили» и «переспроси три раза».

Если делаете прокси для Skype — начинайте с UDP. Всё остальное вторично.