Почему структура C может породить неверный запрос SOCKS
Проверяйте явные ширины полей, порядок байтов и потоковый ввод-вывод, а не считайте раскладку компилятора сетевым форматом.
Корректный адрес прокси не делает корректным написанное вручную сообщение SOCKS. Отправка структуры C или C++ может передать выравнивание или целые числа в порядке хоста, которые протокол никогда не запрашивал.
Для запроса SOCKS5 CONNECT с доменным именем сериализуйте эту последовательность явно после согласования метода и выбранной аутентификации:
- Версия, команда, зарезервированный байт и тип адреса
- Длина домена и байты домена
- Двухбайтовый порт назначения в сетевом порядке байтов
Длины адресов зависят от версии SOCKS и типа адреса. Числовые поля фиксированной ширины требуют заданного представления; строки домена имеют собственную кодировку длины. Терминатор строки C не является общим указанием добавлять ноль к сетевому сообщению.
| Сокращение в реализации | Проблема для проверки |
|---|---|
| Присваивание 32-битного значения через 8-битный указатель | Он не выводит все четыре байта |
| Приведение буфера к указателю на более крупное целое | Выравнивание и порядок байтов всё ещё нужно обрабатывать |
| Предположение, что одно чтение или запись — одно сообщение | TCP может передать лишь часть последовательности протокола |
Сравнивайте каждое поле с предполагаемым назначением и обрабатывайте частичный ввод-вывод. Получение двух байтов не доказывает, что пришёл весь ответ. Проверка этих границ позволяет отличить искажённый запрос от сервера, отвергающего корректно описанное соединение.