Dinamika SSH-plusendado kiel SOCKS-prokurilo super via VPN

Aplikaĵo, kiu parolas nur SOCKS, havas nenion, kun kio ĝi interparolus en ordinara VPN, ĉar la tunelo portas pakaĵojn dum la aplikaĵo volas prokurilan finpunkton. OpenSSH povas provizi tiun finpunkton, kiam la posedanto de la aliro permesas tion, ĉar dinamika plusendado ŝanĝas unu SSH seancon en lokan prokurilon. Poste estas du saltoj, kiujn oni devas teni aparte: la tunelo, kiu atingas la SSH-gastigan komputilon, kaj la konekto, kiun tiu gastiganto poste malfermas. Ilia apartigo klarigas kaj kial la aranĝo funkcias kaj kion ĝi neniam faros.

Kio la SSH-aŭskultanto fariĝas kaj kio ĝi ne fariĝas

Dinamika plusendado igas la SSH-klienton aŭskulti loke kaj paroli SOCKS4 aŭ SOCKS5 kun ĉio, kio konektiĝas. Ĉiu peto nomas celon kaj la SSH-servilo malfermas la pluan konekton, pro kio la cela serĉo povas okazi sur la malproksima flanko. Tio estas TCP-plusendado je aplikaĵa nivelo, ne VPN por la tuta aparato. Ĝi portas nek UDP-asocion, nek ICMP, nek ion por aplikaĵoj, kiuj tute ignoras prokurilajn agordojn. Ankaŭ la salto de la SSH-servilo al la aplikaĵo ne estas ene de via tunelo, kio gravas, kiam la celo akceptas trafikon nur el konataj retoj.

La antaŭkondiĉoj estas realaj: vojo al la SSH-gastiganto, rajtigita konto, kontrolita gastiga ŝlosilo de la servilo kaj permeso plusendi. Nenion el ili kreas la prokurilo, kaj la lasta kutime mankas unue. Konfirmu ĉiujn kvar antaŭ ol diagnozi ion alian, ĉar la malsukceso aspektas same de la kliento, kiu ajn mankas.

Startigu ĝin sur loopback kun eksplicita pordo

Elektu neuzatan lokan pordon kaj ligu ĝin eksplice al loopback anstataŭ lasi la adreson for. La tri opcioj sube ekzistas ĉiu pro unu kialo.

ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  [email protected]

-N preterlasas la malproksiman komandon kaj -T preterlasas la pseŭdoterminalon, do la seanco ekzistas nur por plusendi. ExitOnForwardFailure igas la klienton eliri, kiam la aŭskultanto ne povas esti kreita, anstataŭ funkcii sen la plusendado, kiun vi petis. ControlPath=none tenas la seancon ekster ekzistanta multopleksa konekto, kiu povus aldoni proprajn plusendojn. Loopback tenas la aŭskultanton ekster la LAN, sed sur kunhavigita maŝino ĝi ne estas rajtiga limo, ĉar ankaŭ aliaj lokaj procesoj povas atingi ĝin. La referenco de la OpenSSH-kliento dokumentas ĉiujn tiujn flagojn, kaj la loopback-averto sekvas el tio, kio estas aŭskultanta soketo.

Sendu nomojn tra la prokurilo, ne ĉirkaŭ ĝi

SOCKS5-kliento povas mem solvi la celon aŭ peti la prokurilon fari tion, kaj tiu elekto decidas, kiu solvilo respondas. Kun socks5h curl sendas la gastigan nomon tra la prokurilo, do la serĉo okazas sur la SSH-servilo. Kun ordinara socks5 la tekkomputilo unue solvas kaj vojaĝas nur la konekto, kio silente nuligas la celon, kiam la nomo estas interna. La suba peto ankaŭ malplenigas la liston sen prokurilo, do heredita valoro NO_PROXY ne povas gvidi ĝin ĉirkaŭ la prokurilon.

curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/health

Atestila validigo kaj la propra ensaluto de la aplikaĵo ankoraŭ validas, ĉar la prokurilo anstataŭas nek unu nek la alian. Restas du serĉoj: la tekkomputilo devas atingi la SSH-gastiganton tra la permesita VPN- kaj DNS-vojo, kaj la SSH-servilo devas mem solvi la nomon de la aplikaĵo. La dua estas testebla aparte antaŭ ol ajna trafiko iras tra la prokurilo.

ssh [email protected] getent hosts app.corp.example

Pruvu unu permesitan celon, poste fermu la seancon

Testu celon, kiun la politiko permesas, kaj unu, kiun ĝi devus rifuzi, ĉar funkcianta plusendado pruvas nur, ke la aŭskultanto funkcias, kaj nenion pli. La aplikaĵo vidas la fontan adreson, kiun la SSH-servilo elektas, kaj tio ne estas la tunela adreso de via tekkomputilo. Kie la malproksima flanko registras konektojn laŭ fonto, tiu diferenco estas la unua afero kontrolenda, kiam peto estas rifuzita.

Haltigu la seancon per la proceso, kiu posedas ĝin, anstataŭ mortigi ne rilatan ŝelon. Poste konfirmu, ke la aŭskultanto malaperis, ĉar pordo, kiu ankoraŭ respondas, estas seanco, kiun vi vere ne fermis. Forigu nur la prokurilan agordon, kiun enkondukis ĉi tiu ekzerco, kaj lasu la reston de la aplikaĵa agordo trankvila. Neadministrata terminalo tenanta plusendan regulon ne estas servo, kaj daŭra prokurilo bezonas aprobitan vivciklon, ne forgesitan fenestron.

ss -ltn | grep 1080

Malsukcesoj, kiujn ĉi tiu aranĝo ne povas ripari

Kelkaj simptomoj montras rekte al la limoj supre, kaj frua rekono ŝparas posttagmezon da prokurila diagnozo. La tabelo ligas tion, kion vi vidas, al tio, kion ĝi kutime signifas. Io ajn en la lasta kolumno estas demando pri dezajno, ne eraro en agordo.

La unuaj tri vicoj estas tiuj, kiujn homoj misdiagnozas, ĉar ĉiu produktas konektoprovon anstataŭ eraron pri la prokurilo mem. Nomo, kiu solviĝas sur la tekkomputilo, diras nenion pri la solvilo de la servilo, kaj la malsukceso legeblas anstataŭe kiel atestila aŭ tempolima problemo. Aplikaĵoj nur per UDP staras ekster la dezajno, ne rompitaj ene de ĝi, kaj neniu plia ssh-opcio tion ŝanĝas. La retumila vico estas la ordinara memorigo, ke prokurilaj agordoj estas po aplikaĵo. La lasta vico estas la kialo, ke la ferma kontrolo ekzistas: pordo, kiu ankoraŭ aŭskultas, signifas, ke nun posedas ĝin io alia.