Donu al fora Pi SOCKS-prokurilon per via SSH-kliento

Fora dinamika plusendo metas la SOCKS-aktivulon sur la Pi kaj faras la pluan konekton el la aprobita VPN-vojo de via tekokomputilo. Neniu dua SSH-servilo.

Vi supozas, ke SOCKS-prokurilo devas kuri tie, kie la reta aliro jam ekzistas. OpenSSH povas meti la aktivulon tute aliloke. Fora dinamika plusendo malfermas la SOCKS-pordon sur fora gastiganto kaj originigas ĉiun konekton el via loka SSH-kliento, kiu portas la aprobitan VPN-vojon de via tekokomputilo. La Pi ricevas limigitan prokurilon; ĝi ne heredas vian tunelon aŭ viajn privilegiojn.

La aktivulo kaj la flanko, de kiu la konekto originas, povas malsami

Ordinara ssh -D 1080 funkciigas la aktivulon sur via propra maŝino kaj sendas konektojn de tie. Fora dinamika plusendo renversas tion: la aktivulo aperas sur la fora gastiganto, kaj ĉiu konekto, kiun ĝi akceptas, malfermiĝas el la loka flanko. La manlibro de la OpenSSH-kliento dokumentas -R sen fiksa celo ĝuste kiel ĉi tiun SOCKS4/5-aranĝon.

Subtenata komando el la tekokomputilo aspektas tiel, kun la konto, gastigantoj kaj pordo traktataj kiel lokokupiloj:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

Tri detaloj faras utilan laboron tie. -S none tenas la seancon for de komuna rega majstro, ExitOnForwardFailure malsukcesas rapide anstataŭ lasi vin kun duone malfermita seanco, kaj PermitRemoteOpen limigas, kion la fora aktivulo povas atingi. Uzu rajtigitan Pi-konton kaj kontrolu la gastigantan ŝlosilon antaŭ ol aldoni iun ajn el tio.

Kion la fora aktivulo vere elmontras

Kontrolu la plusendan politikon de la servilo antaŭ ol fidi la aktivulon. Kun GatewayPorts no la fora plusendo restas ligita al loopback, kaj tio estas la elmontro, kiun vi volas. Servilo agordita por devigi ĵokeran plusendon publikigas la saman pordon sur ĉiu interfaco, kio igas personan prokurilon io, kion la loka reto povas atingi.

Loopback ankaŭ ne estas limo por uzanto. Alia procezo sur la Pi povas konektiĝi al 127.0.0.1:1080 se ĝi scias la pordon, do la lokaj kontoj de la Pi kaj ĉio, kio funkcias sur ĝi, estas parto de via alirdesegno. Tio estas kialo teni la celliston mallarĝa, ne kialo preterlasi la politikan kontrolon.

Tenu la permesitan celon specifa por la aplikaĵo, kiun vi provas atingi. Anstataŭigi ĝin per senlima plusendo por igi nerilatan programon funkcii plilarĝigas la vojon multe preter la problemo, kun kiu vi komencis. Cellisto ankaŭ registras, por kio la seanco estis, kio helpas tiun, kiu aŭdos ĝin poste. Skribu ĝin apud la konto, kiun vi uzis.

Sendu unu aplikaĵon tra la prokurilo

Prokuril-konscia kliento sur la Pi povas tiam fari la peton. La prefikso socks5h transdonas la celnomon al la prokurilo, do la serĉo kaj la konekto ambaŭ okazas ĉe la tekokomputila flanko, kaj ĝi kongruas kun la nomita celo en PermitRemoteOpen:

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

Konservu normalan atestilan validigon kaj la propran aŭtentikigon de la aplikaĵo. La prokurilo ŝanĝas, kie la TCP-konekto estas farata; ĝi ne igas neaŭtentikigitan servon sekura, kaj ĝi ne igas memsubskribitan finpunkton fidinda.

La tekokomputilo ankoraŭ bezonas sian propran vojon kaj aliron al la solvilo al kaj la SSH-servilo kaj la aplikaĵo. La trafiko de ĝia SSH-kliento devas esti elektita de la aprobita VPN-politiko, kaj split-tunnel-escepto povas sendi tiun trafikon laŭ malsama vojo ol tiu, kiun vi testis.

Pruvu la vojon kaj fermu ĝin

Konfirmu, ke la aktivulo ekzistas tie, kie vi atendas ĝin, kaj ke nur la intencita celo respondas:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure povas pruvi, ke la plusendo establiĝis, kaj tamen ĝi ne povas atesti, ke la saluto al la aplikaĵo sukcesas malsupre. Testu la aplikaĵon, ne nur la pordon. Aktivulo, kiu akceptas kaj poste malsukcesas ĉiun peton, kutime signifas, ke la celnomo aŭ la vojo de la tekokomputilo estas malĝustaj, ne ke la tunelo malsukcesis.

Ĉi tiu aranĝo portas nur TCP. UDP, ICMP kaj programoj, kiuj ignoras prokurilajn agordojn, restas ekster ĝi, kaj la plusendo finiĝas en la momento, kiam la SSH-seanco finiĝas. Haltigu tiun seancon, kiam vi pretas, kaj forigu la prokurilan agordon, kiun vi aldonis al la aplikaĵo.

Por daŭra aliro, uzu anstataŭe la subtenatan aliĝon de la retposedanto aŭ administritan enirejon. Inversa prokurilo estas la malĝusta ilo por eviti la aparat- aŭ resurslimigojn de VPN; uzata ene de ili, ĝi estas simple unu rajtigita aplikaĵa vojo kun eksplicitaj limoj.

Rilataj artikoloj