SOCKS starpniekserveris var ielādēt ziņas, taču neizdodas zvanos
Izmantojot Dante rokasgrāmatu un SOCKS5 UDP prasības, tiek skaidrots, kāpēc strādājošs TCP ceļš nepierāda lietotnes zvanu trafika atbalstu.
Teksta ziņas nāk caur SOCKS starpniekserveri, taču balss zvans nekad neizveidojas. Starpniekserveris nav obligāti pilnībā sabojāts. Lietotne zvaniem var izmantot citu pārvadi.
Veiksmīgs TCP pieprasījums pierāda TCP ceļu šai darbībai. SOCKS5 arī definē UDP asociāciju, taču klientam, SOCKS pakalpojumam, tīkla noteikumiem un lietotnes iestatījumiem visiem ir jāatbalsta paredzētais UDP maršruts.
Ir vairāk nekā TCP klausītājs
Dante rokasgrāmata atdala protokola un komandu noteikumus, tostarp connect, udpassociate un udpreply. Noteikums, kas atļauj tikai jau pārbaudīto TCP savienojumu, neizveido nepieciešamās UDP atļaujas.
UDP asociācija ietver arī pārsūtīšanas galapunktu un atgriezenisko trafiku. Ugunsmūriem un adrešu tulkošanai jāatļauj tieši šis ceļš. SOCKS TCP klausītāja atvēršana nav tas pats, kas padarīt tā UDP pārsūtītāju sasniedzamu.
Pārbaudiet lietotnes pašreizējo starpniekservera dokumentāciju un iestatījumus. Dažādas versijas var apstrādāt ziņas, medijus un zvanus atšķirīgi. Foruma recepti vecam klientam nevajadzētu pasniegt kā pierādījumu, ka katrs pašreizējais klients maršrutē zvanus caur SOCKS.
Vispirms necentieties atvērt visus UDP portus. Nosakiet pārsūtītāja uzvedību un paredzēto klientu loku, pēc tam piemērojiet atbilstošu ierobežotu tīkla politiku. Tāpat zvaniem paredzētā starpniekservera iestatījuma izslēgšana var likt zvanam darboties, nosūtot to tieši, kas maina ārējo maršrutu, nevis labo starpniekservera maršrutu.
Dokumentējiet panākumus katrā darbībā: ziņas, mediju pārsūtīšana un zvani. Viens strādājošs pieprasījums vai mainīta pārlūkprogrammas IP nevar pierādīt, ka katra citas lietotnes daļa izmanto vienu un to pašu starpniekservera izeju.