SSH-dinamiese deurstuur as ’n SOCKS-proxy oor jou VPN

’n Program wat net SOCKS praat, het niks om mee te praat op ’n gewone VPN nie, want die tonnel vervoer pakkette en die program wil ’n proxy-eindpunt hê. OpenSSH kan daardie eindpunt verskaf wanneer die toegangseienaar dit toelaat, aangesien dinamiese deurstuur een SSH-sessie in ’n plaaslike proxy verander. Dan is daar twee spronge om reg te hou: die tonnel wat die SSH-gasheer bereik, en die verbinding wat daardie gasheer verder maak. Om hulle te skei verduidelik beide waarom die reëling werk en wat dit nooit sal doen.

Wat die SSH-luisteraar wel en nie word nie

Dinamiese deurstuur laat die SSH-kliënt plaaslik luister en SOCKS4 of SOCKS5 praat met alles wat aansluit. Elke versoek noem ’n bestemming en die SSH-bediener open die verbinding verder, en daarom kan die bestemmingsopsoek aan die oorkant gebeur. Dit is toepassingsvlak-TCP-deurstuur, nie ’n VPN vir die hele toestel nie. Dit dra geen UDP-assosiasie, geen ICMP, en niks vir programme wat proxy-instellings heeltemal ignoreer nie. Die sprong van die SSH-bediener na die program is ook nie binne jou tonnel nie, wat saak maak wanneer die bestemming verkeer net van bekende netwerke aanvaar.

Die voorvereistes is werklik: ’n roete na die SSH-gasheer, ’n gemagtigde rekening, ’n geverifieerde gasheer-sleutel van die bediener, en toestemming om deur te stuur. Nie een daarvan word deur die proxy geskep nie, en die laaste een is gewoonlik die eerste wat ontbreek. Bevestig al vier voordat jy enigiets anders ontfout, want die mislukking lyk dieselfde van die kliënt af, watter een ook al ontbreek.

Begin dit op loopback met ’n eksplisiete poort

Kies ’n ongebruikte plaaslike poort en bind dit eksplisiet aan loopback eerder as om die adres weg te laat. Die drie opsies hieronder bestaan elk vir een rede.

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

-N slaan die afgeleë opdrag oor en -T slaan die pseudoterminaal oor, so die sessie bestaan net om deur te stuur. ExitOnForwardFailure laat die kliënt afsluit wanneer die luisteraar nie geskep kan word nie, in plaas daarvan om te loop sonder die deurstuur wat jy gevra het. ControlPath=none hou die sessie uit ’n bestaande gemultiplekse verbinding wat sy eie deurstuurders kan byvoeg. Loopback hou die luisteraar van die LAN af, maar dit is nie ’n magtigingsgrens op ’n gedeelde masjien nie, want ander plaaslike prosesse kan dit ook bereik. Die OpenSSH-kliëntverwysing dokumenteer al hierdie vlae, en die loopback-waarskuwing volg uit wat ’n luisterende socket is.

Stuur name deur die proxy, nie om dit nie

’n SOCKS5-kliënt kan die bestemming self oplos of die proxy vra om dit te doen, en daardie keuse bepaal watter oplosser antwoord. Met socks5h stuur curl die gasheernaam deur die proxy, so die opsoek gebeur op die SSH-bediener. Met gewone socks5 los die skootrekenaar eerste op en net die verbinding reis, wat die punt stilletjies verydel wanneer die naam intern is. Die versoek hieronder skrap ook die geen-proxy-lys, so ’n oorgeërfde NO_PROXY-waarde kan dit nie om die proxy lei nie.

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

Sertifikaatbekragtiging en die program se eie aanmelding geld steeds, want die proxy vervang nie een van die twee nie. Twee opsoeke bly oor: die skootrekenaar moet die SSH-gasheer deur die toegelate VPN- en DNS-pad bereik, en die SSH-bediener moet die programnaam self oplos. Die tweede een is op sy eie toetsbaar voordat enige verkeer deur die proxy gaan.

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

Bewys een toegelate bestemming en sluit dan die sessie

Toets ’n bestemming wat die beleid toelaat en een wat dit behoort te weier, want ’n werkende deurstuur bewys net dat die luisteraar werk en niks meer nie. Die program sien die bronadres wat die SSH-bediener kies, wat nie jou skootrekenaar se tonneladres is nie. Waar die oorkant verbindings volgens bron log, is daardie verskil die eerste ding om na te gaan wanneer ’n versoek verwerp word.

Stop die sessie deur die proses wat dit besit eerder as deur ’n onverwante dop te doodmaak. Bevestig dan dat die luisteraar weg is, want ’n poort wat steeds antwoord is ’n sessie wat jy nie werklik toegemaak het nie. Verwyder net die proxy-instelling wat hierdie oefening ingevoer het, en laat die res van die programkonfigurasie staan. ’n Onbewaakte terminaal met ’n deurstuur-reël is nie ’n diens nie, en ’n permanente proxy het ’n goedgekeurde lewensiklus nodig, nie ’n vergete venster nie.

ss -ltn | grep 1080

Mislukkings wat hierdie reëling nie kan regmaak nie

Sommige simptome wys reguit na die grense hierbo, en om hulle vroeg te herken spaar ’n middag se proxy-ontfouting. Die tabel wys wat jy sien teenoor wat dit gewoonlik beteken. Enigiets in die laaste kolom is ’n ontwerpkwessie eerder as ’n konfigurasiefout.

Die eerste drie rye is dié wat mense verkeerd diagnoseer, want elkeen lewer ’n verbindingspoging eerder as ’n fout oor die proxy self. ’n Naam wat op die skootrekenaar oplos, sê niks oor die bediener se oplosser nie, en die mislukking lees eerder as ’n sertifikaat- of tydverstrykingsprobleem. Slegs-UDP-programme sit buite die ontwerp eerder as dat hulle daarbinne stukkend is, en geen ekstra ssh-opsie verander dit nie. Die blaaier-ry is die gewone herinnering dat proxy-instellings per program geld. Die laaste ry is waarom die afsluitkontrole bestaan: ’n poort wat steeds luister, beteken iets anders besit dit nou.