Indy-ի զրոյական UDP ASSOCIATE հասցեն տվյալագրի նպատակը չէ

Առանձնացրեք հաճախորդի ասոցիացիայի հասցեն, վերադարձված SOCKS ռելեն և յուրաքանչյուր UDP փաթեթում կոդավորված նպատակը։

0.0.0.0:0-ը Indy UDP ASSOCIATE հարցման մեջ կարող է դիտավորյալ լինել։ Այդ հարցումը նկարագրում է հաճախորդի կողմի սպասվող UDP վերջնակետը, և RFC 1928-ը թույլատրում է զրոներ, երբ այն անհայտ է։ Այն չի ընտրում վերջնական ծառայությունը։

Պատասխանի BND.ADDR/BND.PORT-ը նշում է ռելեն, որին հաճախորդն ուղարկում է փաթեթավորված տվյալագրերը։

TCP control: client → SOCKS5 proxy → UDP association reply
UDP payload: client → returned relay address → target service

Indy-ում TIdUDPClient.Connect-ը կանչում է թափանցիկ պրոքսիի OpenUDP-ը։ TIdSocksInfo-ը տրամադրում է զրոյական ասոցիացիայի դաշտերը։ Ավելի ուշ SendBuffer-ը ցանկալի ծառայությունը փոխանցում է SendToUDP-ին, որը կառուցում է SOCKS UDP նպատակակետի վերնագիրը հավելվածի տվյալներից առաջ։

Եթե ասոցիացիան հաջողվում է, բայց երթևեկությունը ձախողվում է, ստուգեք վերադարձված ռելեն, կոդավորված նպատակակետը և UDP պատասխանի ուղին։ NAT/հրմշտոցները կարող են թույլատրել TCP փոխանակումը՝ արգելափակելով UDP-ն։

TCP կառավարման միացումը բաց պահեք․ փակելը դադարեցնում է ասոցիացիան։ SOCKS4/4a-ն չունեն այս գործողությունը, և միայն SOCKS5 անվանումը չի երաշխավորում, որ սերվերը աջակցում է UDP-ին։

Առնչվող հոդվածներ