Как понять, что именно блокирует ваше соединение

То, как именно отказывает соединение, само по себе диагностично. Прежде чем что-либо делать, сопоставьте увиденное с этой таблицей.

Манипуляция DNS — самая дешёвая форма блокировки и потому самая распространённая, и её же проще всего подтвердить или исключить. Проверка в том, чтобы задать один и тот же вопрос двум разным резолверам и сравнить ответы.

1. 1

   Спросите резолвер своей сети

   Выполните `nslookup example.com` (Windows) или `dig example.com` (macOS и Linux) без дополнительных аргументов, чтобы использовался тот резолвер, который выдала сеть.

2. 2

   Спросите публичный резолвер напрямую

   Выполните `nslookup example.com 1.1.1.1` или `dig @1.1.1.1 example.com`. Это обходит собственный резолвер сети — при условии, что исходящий DNS вообще разрешён.

3. 3

   Сравните ответы

   Разные адреса, ответ 0.0.0.0 или 127.0.0.1, либо NXDOMAIN от одного и корректный ответ от другого — всё это указывает на перехват. Одинаковые ответы исключают DNS.

4. 4

   Если и второй запрос падает или возвращает тот же неверный ответ

   Скорее всего, сеть перенаправляет весь трафик на порт 53 в собственный резолвер, что встречается часто. Противодействие — шифрованный DNS (DNS-over-HTTPS или DNS-over-TLS), который сейчас нативно поддерживает большинство операционных систем.

Чётко понимайте, что даёт починка DNS. Она даёт вам правильный адрес. Она никак не влияет на то, разрешено ли вам до этого адреса дойти, а имя хоста всё равно будет ещё раз отправлено открытым текстом в последующем рукопожатии TLS. Проблемы с DNS и проблемы с соединением — разные вещи, и нередко присутствуют обе сразу.

Если имя разрешается правильно, но ничего не подключается, следующий вопрос — недоступен ли адрес или же останавливают именно то, что вы пытаетесь с ним делать. Из приложения это выглядит одинаково, а в командной строке различается легко.

1. 1

   Проверьте порт простым TCP-соединением

   На macOS или Linux: `nc -vz <адрес> 443`. На Windows: `Test-NetConnection <адрес> -Port 443`. Это открывает голое TCP-соединение и больше ничего.

2. 2

   Истолкуйте результат

   Если TCP-соединение установилось, адрес и порт доступны, и проблема в протоколе, на котором вы поверх них говорите: фильтр классифицировал трафик. Если падает сам TCP, адрес или порт заблокированы целиком.

3. 3

   Проверьте второй порт на том же адресе

   Если 443 падает, а другой порт работает, блокировка привязана к порту. Если падают все порты, заблокирован адрес.

4. 4

   Проверьте другую конечную точку

   Если другой адрес работает с теми же настройками и тем же протоколом, первый адрес внесён в список блокировки, и никакая подстройка протокола его не вернёт.

Это различение — самое ценное в данном руководстве. Блокировка адреса требует другой конечной точки. Блокировка протокола требует другого протокола или транспорта. Применение не того средства создаст впечатление, что проблема неразрешима.

Соединение, которое устанавливается, пропускает немного трафика и затем резко умирает, — это другая сигнатура, нежели соединение, которое не устанавливается вовсе. Обычно это значит, что фильтру потребовалось увидеть несколько байтов, чтобы классифицировать поток, после чего он убил его подделкой сброса TCP от имени другой стороны.

• Это воспроизводимо и быстро — обычно в пределах секунды-двух и каждый раз в одной и той же точке. Настоящие неисправности ведут себя беспорядочно.
• Другая сторона об этом не знает. С точки зрения сервера клиент просто исчез.
• Момент привязан к рукопожатию, а не к объёму: передача большего количества данных не приближает обрыв.

Если у вас есть инструмент захвата пакетов, сброс, пришедший со значением TTL, заметно отличающимся от остальных пакетов того же потока, — сильный признак вброса, поскольку он был порождён ближе к вам, чем находится настоящая конечная точка. Это подтверждение, а не то, что нужно для действия.

Средство лежит на уровне протокола: классификатор что-то опознал, значит ответ — транспорт, который этого не предъявляет. Смена конечной точки не поможет, потому что с новой произойдёт та же классификация.

Труднее всего подтвердить случай, когда соединение работает, но слишком медленно для использования, потому что без контрольного измерения оно неотличимо от обычной перегрузки.

1. 1

   Измерьте туннель

   Прогоните тест пропускной способности через туннель и запишите результат, желательно несколько раз в течение нескольких минут.

2. 2

   Измерьте без него, в тот же момент

   Прогоните тот же тест напрямую. Большой разрыв, сохраняющийся при повторных прогонах, — первое свидетельство.

3. 3

   Смотрите на форму, а не только на число

   Замедляемые потоки характерно начинаются быстро на секунду-другую — пока классификатор не принял решение — и затем оседают на низкой и необычно стабильной скорости. Настоящая перегрузка колеблется. Стабильность на низкой скорости и есть примета.

4. 4

   Попробуйте другой порт и другую конечную точку

   Если потолок следует за протоколом независимо от конечной точки, это шейпинг на основе классификации. Если он следует за конечной точкой, скорее всего дело в её пропускной способности.

Самая информативная проверка не стоит ничего: попробуйте ту же конфигурацию в другой сети — мобильные данные вместо Wi-Fi или совсем другая сеть Wi-Fi.

• Работает в одной сети и не работает в другой: политика принадлежит сети, а не вашему устройству, конфигурации или конечной точке. С вашей стороны чинить нечего.
• Не работает ни в одной сети: проблема в конечной точке, конфигурации или учётных данных, и искать надо там.
• Работает в обеих, но в одной медленно: эта сеть шейпит, а не блокирует.

Политика фильтрации со временем меняется, и тот же симптом через три месяца может иметь другую причину. Несколько строк с датой, сетью, симптомом, тем, что вы поменяли, и результатом превращают каждый случай в нечто, на что можно опереться, вместо того чтобы каждый раз начинать то же расследование с нуля.