SSH-ով փոխանցված պորտը միշտ չէ, որ SOCKS վստահված սերվեր է
Տարբերակեք SSH-ի հաստատուն տեղական փոխանցումը դինամիկ SOCKS լսողից՝ նախքան հավելվածը կարգավորելը։
Դուք ստեղծում եք SSH թունել, 127.0.0.1-ը և դրա պորտը մտցնում եք դիտարկիչի վստահված սերվերի կարգավորումների մեջ, և ոչինչ չի բեռնվում։ Լսողը կարող է բացարձակ ճիշտ աշխատել։ Գուցե այն պարզապես սպասում է երթևեկության սխալ տեսակի։
| Փոխանցում | Ինչ է ուղարկում տեղական հավելվածը | Նպատակակետի ընտրություն |
|---|---|---|
-L | Թիրախային ծառայության սովորական արձանագրությունը | Ամրագրված է SSH հրահանգում |
-D | SOCKS բանակցություն, ապա հավելվածի երթևեկություն | Պահանջվել է SOCKS հաճախորդի կողմից |
Մեկ վեբ սերվերի համար սա հաստատուն փոխանցում է՝
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Այցելեք http://127.0.0.1:9080/ որպես վեբկայք։ Մի պիտակավորեք 9080 պորտը որպես SOCKS․ այն բայթեր է փոխանցում հրահանգում նշված միակ վեբ սերվերին։ Կայքը այլ հոսթանունով բացելը կարող է նաև ազդել դրա վիրտուալ հոսթինգի, վերահղումների կամ քուքիների վրա։
SOCKS լսողի համար ձևը փոխվում է՝
ssh -N -D 127.0.0.1:1080 [email protected]Կարգավորեք հավելվածը, որ օգտագործի SOCKS 127.0.0.1:1080 հասցեով։ Այդ հասցեն ուղիղ դիտարկիչի հասցեագոտու մեջ մտցնելը վեբ հարցումն ուղարկում է SOCKS լսողին՝ արձանագրության ևս մեկ անհամապատասխանություն։
OpenSSH ձեռնարկը փաստագրում է երկու ձևերը։ Կա օգտակար բացառություն․ գոյություն ունեցող HTTP վստահված սերվերը -L -ով փոխանցելը ստեղծում է տեղական պորտ, որը խոսում է HTTP վստահված սերվերի արձանագրությամբ, քանի որ դրա հաստատուն նպատակակետը ինքն է HTTP վստահված սերվեր։ Հեռավոր ծայրի ծառայությունն է որոշում, թե ինչ է պատկանում հաստատուն փոխանցմանը։ Գոյություն ունեցող վստահված սերվերի փոխանցումը SSH-ով պահպանում է այդ վստահված սերվերի արձանագրությունն ու հաշիվը։