Сокету .NET потрібне рукостискання SOCKS

Спрямування Socket.Connect() на сервер SOCKS відкриває TCP-з'єднання з цим сервером. Наступні байти все ще мають розмовляти SOCKS. Якщо негайно надіслати протокол застосунку, сервер чекатиме на іншу розмову.

У SOCKS5 встановлення з'єднання включає узгодження методу, будь-який вибраний обмін автентифікації та запит із зазначенням призначення. Лише успішна відповідь відкриває шлях для байтів застосунку. Ці етапи визначені в RFC 1928.

Тримайте узгодження на рівні з'єднання

Застосунок із власним протоколом TCP може використовувати конектор, який розуміє проксі й повертає встановлений потік. Решта застосунку читає й пише через цей потік. Конектор має враховувати часткові читання, адреси змінної довжини, збої автентифікації та граничний термін для узгодження.

Написана вручну реалізація, яка читає один буфер фіксованого розміру й припускає успіх, є крихкою. TCP не зберігає межі повідомлень SOCKS. Прочитайте повну відповідь, описану її типом адреси, перш ніж запускати протокол застосунку. Зчитувач відповідей CONNECT для .NET 7+ ілюструє цей крок.

Якщо підтримувана бібліотека вже надає цей рівень з'єднання, перевірте підтримувані нею версії SOCKS, методи автентифікації та цільову платформу. Посилання на форум десятирічної давності — це відправна точка для дослідження, а не доказ поточної сумісності.

Конфігурація HTTP-клієнта має окрему область

Налаштування проксі в HTTP-клієнті конфігурує цей HTTP-клієнт. Воно не змінює кожен сирий сокет у процесі. API Socket приймає мережеву кінцеву точку й залишає узгодження вищого рівня викликачеві.

Для зашифрованого протоколу застосунку виконайте його рукостискання TLS після встановлення проксі-тунелю. На цьому етапі перевірте передбачувану ідентичність призначення. Автентифікація проксі й автентифікація призначення залишаються окремими, навіть якщо вони використовують той самий базовий потік.