Jy aanvaar dat 'n SOCKS-volmag moet loop waar die netwerktoegang reeds bestaan. OpenSSH kan die luisteraar heeltemaal elders plaas. 'n Afgeleë dinamiese aanstuur maak die SOCKS-poort op 'n afgeleë gasheer oop en laat elke verbinding by jou plaaslike SSH-kliënt ontstaan, wat jou skootrekenaar se goedgekeurde VPN-roete dra. Die Pi kry 'n beperkte volmag; dit erf nie jou tonnel of jou voorregte nie.

Die luisteraar en die oorsprongkant kan verskil

'n Gewone ssh -D 1080 laat die luisteraar op jou eie masjien loop en stuur verbindings daarvandaan uit. 'n Afgeleë dinamiese aanstuur draai dit om: die luisteraar verskyn op die afgeleë gasheer, en elke verbinding wat hy aanvaar, word van die plaaslike kant oopgemaak. Die OpenSSH-kliënthandleiding beskryf -R sonder 'n vaste bestemming as presies hierdie SOCKS4/5-reëling.

'n Ondersteunde opdrag vanaf die skootrekenaar lyk so, met die rekening, die gashere en die poort as plekhouers:

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

Drie besonderhede doen nuttige werk daar. -S none hou die sessie weg van 'n gedeelde kontrolemeester, ExitOnForwardFailure misluk vinnig in plaas daarvan om jou met 'n halfope sessie te laat, en PermitRemoteOpen beperk wat die afgeleë luisteraar mag bereik. Gebruik 'n gemagtigde Pi-rekening en verifieer die gasheersleutel voordat jy enigiets daarvan byvoeg.

Wat die afgeleë luisteraar werklik blootstel

Kontroleer die bediener se aanstuurbeleid voordat jy op die luisteraar staatmaak. Met GatewayPorts no bly die afgeleë aanstuur aan loopback gebind, en dit is die blootstelling wat jy wil hê. 'n Bediener wat gekonfigureer is om wildcard-aansturing te forseer, publiseer dieselfde poort op elke koppelvlak, wat 'n persoonlike volmag verander in iets wat die plaaslike netwerk kan bereik.

Loopback is ook nie 'n grens per gebruiker nie. 'n Ander proses op die Pi kan aan 127.0.0.1:1080 koppel as dit die poort ken, so die Pi se plaaslike rekeninge en alles wat daarop loop, is deel van jou toegangsontwerp. Dit is 'n rede om die bestemmingslys smal te hou, nie 'n rede om die beleidskontrole oor te slaan nie.

Hou die toegelate bestemming spesifiek vir die toepassing wat jy probeer bereik. Om dit met onbeperkte aansturing te vervang sodat 'n onverwante program werk, verbreed die pad ver verby die probleem waarmee jy begin het. 'n Bestemmingslys teken ook aan waarvoor die sessie was, wat elkeen help wat dit later ouditeer. Skryf dit neer langs die rekening wat jy gebruik het.

Stuur een toepassing deur die volmag

'n Volmagbewuste kliënt op die Pi kan dan die versoek maak. Die socks5h-voorvoegsel gee die bestemmingsnaam aan die volmag, so die opsoek en die verbinding gebeur albei aan die skootrekenaar se kant, en dit stem ooreen met die benoemde bestemming in PermitRemoteOpen:

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

Hou normale sertifikaatvalidering en die toepassing se eie verifikasie. Die volmag verander waar die TCP-verbinding gemaak word; dit maak nie 'n ongeverifieerde diens veilig nie, en dit verander nie 'n selfondertekende eindpunt in 'n vertroude een nie.

Die skootrekenaar het steeds sy eie roete en oplosser-toegang tot beide die SSH-bediener en die toepassing nodig. Sy SSH-kliënt se verkeer moet deur die goedgekeurde VPN-beleid gekies word, en 'n split-tonnel-uitsluiting kan daardie verkeer op 'n ander pad as die een wat jy getoets het, stuur.

Bewys die pad en sluit dit

Bevestig dat die luisteraar bestaan waar jy dit verwag en dat net die bedoelde bestemming antwoord:

$ 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 kan bewys dat die aansturing gevestig is, en dit kan steeds nie sertifiseer dat die toepassing se aanmelding stroomaf slaag nie. Toets die toepassing, nie net die poort nie. 'n Luisteraar wat aanvaar en dan elke versoek laat misluk, beteken gewoonlik dat die bestemmingsnaam of die skootrekenaar se roete verkeerd is, nie dat die tonnel gefaal het nie.

Hierdie reëling dra net TCP. UDP, ICMP en programme wat volmaginstellings ignoreer, bly daar buite, en die aansturing eindig die oomblik wanneer die SSH-sessie eindig. Stop daardie sessie wanneer jy klaar is en verwyder die volmaginstelling wat jy by die toepassing bygevoeg het.

Vir permanente toegang, gebruik eerder die netwerkeienaar se ondersteunde inskrywing of bestuurde poort. 'n Omgekeerde volmag is die verkeerde instrument om 'n VPN se toestel- of hulpbronbeperkings te ontduik; binne daardie beperkings gebruik, is dit bloot een gemagtigde toepassingspad met uitdruklike perke.

Verwante artikels