Заблокированные порты
Прокси-провайдер может запрещать подключения к определённым сетевым портам. Например, разрешать просмотр веб-сайтов, но закрывать соединения с портами отправки почты. Сам прокси при этом принимает подключение клиента, однако соединение с почтовым сервером на запрошенном порту не устанавливает.
Ограничения портов — один из видов ограничений использования прокси, от которых зависит пригодность сервиса для вашей задачи. Чтобы понять их действие, нужно различать подключение к самому прокси и соединение, которое он устанавливает по вашему запросу.
Какой именно порт блокируется
Сетевой порт — это номер, с помощью которого различают службы на одном сетевом адресе. Один сервер может принимать веб-подключения на одном порту, а обращения к другому приложению — на другом. Программе нужны адрес сервера, подходящий порт и используемый транспорт: TCP или UDP.
При работе через прокси есть два разных адресата. Сначала программа подключается к прокси по адресу и порту, выданным провайдером. Затем она просит прокси обратиться к целевому серверу по его адресу и порту. Порт в настройках прокси относится к первому этапу, а ограничение порта назначения — ко второму.
Например, программа подключается к proxy.example:1080 и запрашивает соединение с portal.example:443. Через тот же входной порт прокси она может запросить mail.example:587. Если провайдер разрешает первый порт назначения и блокирует второй, веб-подключение может пройти, а почтовое будет отклонено.
Такие ограничения касаются исходящих соединений от прокси к внешним сервисам. Разрешение на это соединение не создаёт входной порт для программы на вашем компьютере, к которому смогут обращаться другие пользователи интернета. Проброс входящих подключений — отдельная возможность.
Зачем провайдеры закрывают порты
Самая понятная причина — предотвращение злоупотреблений определённым сервисом. Прямой доступ к почтовым серверам можно использовать для рассылки спама. Жалобы и попадание в списки нежелательных отправителей затрагивают IP-адреса, с которых идёт трафик, поэтому последствия могут выйти за пределы аккаунта отправителя. Провайдер снижает этот риск, отклоняя подключения к портам отправки почты ещё до передачи писем.
Похожая логика может применяться к удалённому администрированию, файловым службам или базам данных. Провайдер может ограничивать доступ к связанным с ними портам, чтобы сократить попытки несанкционированного входа и другие атаки. Ограничение действует на само соединение: через такой продукт даже администратор собственного сервера может не получить к нему доступ.
Правило не всегда устанавливает сам продавец прокси. Хостинг или сетевой оператор может фильтровать исходящие соединения инфраструктуры, на которой работает прокси. Разрешение в программе прокси не отменяет запрет, действующий дальше по маршруту.
Фильтрация по порту — достаточно грубая мера. Она позволяет останавливать нежелательный трафик без проверки каждого сообщения и оценки допустимости каждой отдельной операции, но одновременно ограничивает полезные приложения, которым нужен тот же порт. Поэтому провайдер может сохранять запрет и для платящего клиента с обоснованной задачей.
Как работают правила доступа к портам
Есть два основных подхода. В чёрный список вносят порты, которыми клиентам нельзя пользоваться; остальные соединения рассматриваются с учётом других правил сервиса. Белый список действует в обратную сторону: провайдер разрешает определённый набор портов и отклоняет остальные. Во втором случае обычное веб-приложение на нестандартном порту может оказаться недоступным просто потому, что его порт не входит в разрешённый набор.
Правило может закрывать порт на всех внешних адресах либо учитывать одновременно порт и конкретный адрес назначения. Провайдер также может применять разные правила к разным продуктам или согласованным задачам. Поэтому доступ через одну сеть ещё не определяет возможности другого продукта той же компании.
Для проверки порта назначения прокси не нужно расшифровывать трафик приложения. В запросе HTTP CONNECT клиент указывает целевой адрес и порт. В SOCKS5 нужный адрес назначения также передаётся в запросе на соединение. Прокси может отклонить этот запрос ещё до начала защищённого сеанса с целевым сервером.
Один и тот же номер порта у TCP и UDP можно разрешать или блокировать отдельно. Успешное подключение к TCP-порту 443 не доказывает доступность UDP-порта 443. Возможен и другой случай: выбранный прокси-продукт вообще не передаёт UDP. Тогда ограничение относится к транспорту, а не к одному конкретному UDP-порту.
Сам номер порта также не доказывает, что именно делает приложение. Службы могут работать на нестандартных портах, а разрешённый номер не делает допустимым любое его использование. Провайдер может сочетать фильтрацию портов с ограничениями адресов назначения и правилами самой деятельности.
Как это влияет на приложения
Приложения устанавливают соединения для конкретных функций. Если в браузере открылся сайт, это подтверждает работу конкретного веб-подключения. Другой программе могут понадобиться соединения, которые такая проверка не охватывает. На следующих примерах видно, как ограничение порта влияет на работу сервиса.
| Подключение | Порты в этом примере | Последствие ограничения |
|---|---|---|
| Веб-доступ по TCP | 443 | Через это соединение не удаётся получить страницу. |
| Отправка почты | TCP 25 для передачи между серверами; TCP 465 или 587 для отправки из почтовой программы | Прямая отправка почты через затронутое соединение недоступна. |
| Пассивный FTP | TCP 21 для команд и отдельный порт, сообщённый сервером для данных | Вход может пройти, а получение списка файлов или передача — не работать. |
| Веб-приложение на нестандартном порту | Например, TCP 8443 | Приложение может быть недоступно, хотя сайты на TCP 443 открываются. |
Особенно хорошо различие видно на примере почты. Почтовая программа передаёт исходящие письма почтовому серверу, обычно на порту 587 или 465. На порту 465 соединение сразу начинается с шифрования TLS; на порту 587 для перехода к шифрованию обычно используется STARTTLS. Ограничение порта может остановить любое из этих соединений до отправки письма. Шифрование защищает обмен, но не отменяет правило доступа у провайдера.
В веб-интерфейсе почты браузер общается с сайтом по HTTPS, а доставкой письма занимается почтовый сервис. Браузер не просит прокси установить то же самое SMTP-соединение. Поэтому веб-почта может оставаться доступной при заблокированном SMTP. Получение писем отдельной программой — ещё одно соединение: доступ по IMAP или POP нужно рассматривать отдельно от отправки.
FTP показывает, почему одной проверки входа бывает недостаточно. В пассивном режиме клиент сначала передаёт команды по одному соединению, а затем подключается к сообщённому сервером порту для передачи данных. Если второе соединение ограничено, авторизация может работать, а список файлов или скачивание — нет. Похожий частичный отказ возможен у приложений с отдельными соединениями для входа, голоса или обмена файлами.
Почему смена настроек прокси может не помочь
Замена входного порта в настройках прокси меняет точку, к которой обращается ваша программа. Она не меняет порт назначения, запрошенный для внешнего сервиса. Если провайдер предоставляет вход на порту 443, подключение к нему всё равно оставляет запрос к порту 587 почтового сервера под действием почтового ограничения.
Переход с HTTP-прокси на SOCKS5 может решить проблему совместимости, если приложению нужна возможность, поддерживаемая новым способом подключения. Сам по себе он не отменяет правила провайдера. SOCKS5 описывает, как запрашивать TCP-соединения и передачу UDP; сервис определяет, какие из этих запросов он принимает.
Замена выходного IP также сохраняет запрет, установленный для всего продукта. Другой маршрут может вести себя иначе, если причина отказа связана с конкретной внешней сетью, но ротация не снимает правило, действующее для продукта целиком. Большее количество IP или увеличенный объём трафика сами по себе тоже не меняют разрешение.
Как определить, связано ли ограничение с портом
Самое полезное свидетельство — явный ответ провайдера о том, что запрошенный порт назначения запрещён. Общее сообщение об отказе в доступе менее точно. Например, ответ SOCKS5 об отклонении запроса правилами сервера указывает на запрет, но не сообщает, какое именно правило сработало. Один тайм-аут или разрыв соединения даёт ещё меньше информации.
На целевом сервере может не быть службы, принимающей подключения на этом порту; сервер также может допускать только определённые исходные адреса или быть временно недоступным. Сама программа может использовать неправильный протокол либо отправлять часть трафика в обход настроенного прокси. Одна успешная проверка веб-запроса не позволяет отличить эти причины от ограничения другого соединения.
Для содержательного обращения в поддержку укажите прокси-продукт, целевое имя сервера или IP, его порт, TCP или UDP, приложение, точный текст ошибки и время попытки. Эти сведения позволяют проверить нужное соединение, а не только доступность самого прокси. Перед покупкой та же информация помогает выяснить, подходит ли продукт для задачи.
Если провайдер допускает исключения, согласование должно относиться к нужному адресу назначения и задаче. Некоторые ограничения остаются постоянными или зависят от инфраструктуры, которой провайдер не управляет. Полезно выяснить, может ли сервис обеспечить конкретное соединение в рамках своих правил: просьба «открыть все порты» не объясняет ни потребность, ни допустимые границы.