Un proxy SOCKS poate încărca mesaje, dar eșuează la apeluri
Folosind manualul Dante și cerințele UDP din SOCKS5 se explică de ce o cale TCP funcțională nu dovedește suport pentru traficul de apeluri al unei aplicații.
Mesajele text ajung printr-un proxy SOCKS, dar un apel vocal nu se conectează niciodată. Proxy-ul nu este neapărat complet defect. Aplicația poate folosi alt transport pentru apeluri.
O cerere TCP reușită dovedește o cale TCP pentru acea operațiune. SOCKS5 definește și asocierea UDP, dar clientul, serviciul SOCKS, regulile de rețea și setările aplicației trebuie toate să accepte ruta UDP dorită.
Există mai mult decât un ascultător TCP
Manualul Dante separă regulile de protocol și de comandă, inclusiv connect, udpassociate și udpreply. O regulă care permite doar conexiunea TCP deja testată nu stabilește permisiunile UDP necesare.
Asocierea UDP implică și un punct final de retransmisie și trafic de retur. Paravanele și traducerea adreselor trebuie să permită acea cale reală. Deschiderea ascultătorului TCP al SOCKS nu echivalează cu a face retransmițătorul său UDP accesibil.
Verificați documentația și setările actuale de proxy ale aplicației. Versiunile diferite pot trata diferit mesajele, media și apelurile. O rețetă de forum pentru un client vechi nu trebuie prezentată ca dovadă că fiecare client actual dirijează apelurile prin SOCKS.
Evitați deschiderea tuturor porturilor UDP ca prim diagnostic. Determinați comportamentul retransmisiei și aria dorită de clienți, apoi aplicați politica de rețea restricționată potrivită. La fel, dezactivarea unei setări de proxy pentru apeluri poate face un apel să funcționeze trimițându-l direct, ceea ce schimbă ruta spre exterior în loc să o repare pe cea prin proxy.
Documentați succesul pe operațiune: mesaje, transfer de media și apeluri. O singură cerere funcțională sau un IP de browser schimbat nu pot dovedi că fiecare parte a unei alte aplicații partajează aceeași ieșire de proxy.