UDP tra la SOCKS-pordo de Tor: kio ne estas portata
La SOCKS-interfaco de Tor akceptas fluajn konektojn, ne arbitrajn datagramojn. Rulu la kontrolon laŭorde, poste elektu transporton, kiun la aplikaĵo vere subtenas.
Montri aplikaĵon al SOCKS-pordo funkcias por retumilo kaj malsukcesas por ludo, kaj la kialo ne estas agordo. SOCKS5 difinas plurajn komandojn, kaj efektivigo rajtas subteni nur kelkajn el ili; la interfaco de Tor akceptas fluajn konektojn kaj nomrezolucion, ne arbitran plusendadon de datagramoj. Kliento, kiu sendas UDP kaj atendas, ke la prokurilo plusendu ĝin, petas komandon, kiun la servilo ne efektivigas. La gvidilo sube kontrolas tion en kelkaj minutoj kaj poste elektas transporton, kiu povas vere funkcii.
Kontrolu, kion la aplikaĵo vere sendas
Komencu per identigo de la transporto, ne de la protokola nomo. Voĉa kliento povas ensaluti per HTTPS kaj poste porti la aŭdvidan enhavon per UDP; ludo povas aŭtentigi per TCP kaj ludi per UDP; dosiera transdono povas uzi TCP por regado kaj UDP por malkovro. La unuaj du kondutoj aspektas identaj ĝis la ensaluto sukcesos kaj la voko ankoraŭ malsukcesos, kaj tial «ĝi konektiĝis» ne estas pruvo, ke la tuta aplikaĵo funkcias. Iuj klientoj ankaŭ mem refalas de UDP al TCP, kio igas parte funkciantan seancon aspekti kiel malstabila reto anstataŭ blokita transporto.
Notu la celan pordon kaj la transporton por la parto, kiu malsukcesas. Tiu unu linio decidas, ĉu prokurilo entute povas helpi.
Kion akceptos la SOCKS-interfaco de Tor
Tor efektivigas la komandon SOCKS5 CONNECT por fluaj konektoj kaj etendajn komandojn por solvi nomojn, kaj tial retumilo funkcias tra ĝi senŝanĝe. UDP ASSOCIATE, la komando, kiu permesus al kliento transdoni datagramojn al la prokurilo por plusendado, ne estas parto de tio, kion Tor proponas. La dokumentaro pri la etendoj troviĝas en la specifo de SOCKS-etendoj de la projekto, kaj ĝi estas mallonga. La manko de komando por datagramoj estas intenca: plusendi arbitran UDP donus al la reto plusendan rolon, por kiu ĝi neniam estis desegnita.
Tio estas ankaŭ la respondo por WireGuard, kiu estas UDP laŭ dizajno kaj havas neniun rezervan vojon per TCP. Ne ekzistas subtenata vojo, kiu direktus WireGuard al SOCKS-pordo, kaj ĉio, kio asertas la malon, estas envolvilo kun propra rakonto pri fido kaj prizorgado, ne trajto de iu el la du iloj.
OpenVPN estas la parta escepto, ĉar ĝi povas esti agordita por tuneli tra TCP kaj ĝi komprenas la opcion de SOCKS-prokurilo. Tio tamen postulas servilon agorditan por TCP kaj konscian decidon pri la sekvoj por rendimento kaj fingrospuro, do ĝi estas desegna elekto, ne riparo de kongruo.
Rulu la kontrolon laŭorde
Unue konfirmu, ke la prokurilo funkcias por fluoj, por ke posta malsukceso ne estu atribuata al neatingebla pordo. Poste konfirmu la propran trafikon de la aplikaĵo kaj observu, kiujn soketojn ĝi vere malfermas.
curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'
Sukcesa unua komando kaj establita fluo en la dua linio montras, ke la vojo tra la prokurilo funkcias laŭ la desegno. La tria komando serĉas lokajn datagramajn soketojn apartenantajn al la aplikaĵo; se la kliento malfermas unu kaj sendas rekte al malproksima adreso, ĝi neniam konsultis la prokurilon kaj neniu prokurila agordo tion ŝanĝos. Se ĝi malsukcesas ĉe la unua paŝo, haltu kaj riparu la vojon tra la prokurilo antaŭ ol esplori la aplikaĵon, ĉar du fuŝoj samtempe produktas raporton, pri kiu neniu povas agi.
Retroiru kaj elektu la ĝustan ilon
Forigu ĉiujn prokurilajn medio-variablojn aŭ agordojn de prokurilo por unuopa aplikaĵo, kiuj direktis la UDP-klienton al la SOCKS-pordo; lasi ilin resti igas postajn testojn ambiguaj. Restarigu la antaŭan agordon el kopio, restartigu la aplikaĵon kaj konfirmu, ke la originala konduto revenas, por ke la komparo estu pura. Retroigo, kiu ne estas kontrolita, estas nur espero, ke la stato ŝanĝiĝis.
Por transporto, kiu devas resti UDP, VPN kutime pli taŭgas: ĝi portas la pakaĵojn de la aplikaĵo sen postuli, ke la aplikaĵo parolu prokurilan protokolon, je la kosto de tute aliaj anonimecaj ecoj. Uzu ĉiun ilon por tio, kion ĝi dokumentas, kaj traktu ajnan ponton inter ili kiel apartan sistemon, kiu bezonas sian propran revizion. Notu en la fina raporto, kiu tavolo portas kiun transporton, por ke la sekva persono ne remalkovru la saman limon kun alia aplikaĵo.