Ĉu ĉi tiu RouterOS SOCKS-servo subtenas vian pasvortan saluton?
Kontrolu la instalitan RouterOS-version kaj la SOCKS5-aŭtentigan subtenon de la kliento, poste tenu SOCKS-kontojn aparte de retprokuraj kaj enkursigilaj administraj agordoj.
La manlibro pri RouterOS SOCKS dokumentas SOCKS5-pasvortan aŭtentigon kaj apartan liston de SOCKS-uzantoj. Tio respondas al trajta demando por eldonoj, kiuj havas tiujn regilojn, sed ne promesas, ke pli malnova enkursigilo havas ilin.
En la dokumentita aranĝo ambaŭ flankoj devas interkonsenti:
- La enkursigilo elektas SOCKS5 kaj aŭtentigan metodon, kiu postulas pasvortan intertraktadon, kun aparta ebligita SOCKS-uzanto.
- La kliento realigas SOCKS5-intertraktadon de uzantnomo kaj pasvorto. Ensaluta kampo de HTTP-prokuro aŭ SOCKS-realigo nur sen aŭtentigo ne sufiĉas.
Uzu la kampojn, kiujn subtenas la instalita eldono. Se eldono ne havas ilin, elektu ĝian subtenatan dezajnon aŭ aprobitan alternativon anstataŭ kopii kampojn de pli nova manlibro.
Ĉi tiuj estas SOCKS-kontoj. Ili nek pruvas, ke la aparta HTTP-retprokuro de RouterOS prezentas la saman interfacon, nek postulas doni administran aliron al la enkursigilo. Tenu ankaŭ limigitaj la alirpolitikon fonto/celo kaj la fajroŝirmilon de la enkursigilo.
La pasvorta metodo mem ne ĉifras la akredigilojn: la RFC 1929-intertraktado antaŭas ĉiun postan HTTPS-kunsidon kun retejo. Uzu taŭge protektitan vojon de la kliento al la enkursigilo; TLS ĉe la celo ne povas retroaktive protekti tiun pli fruan interŝanĝon.