Տվեք հեռավոր Pi-ին SOCKS վստահված սերվեր ձեր SSH հաճախորդի միջոցով

Դուք ենթադրում եք, որ SOCKS վստահված սերվերը պետք է աշխատի այնտեղ, որտեղ ցանցային հասանելիությունն արդեն կա։ OpenSSH-ը կարող է լսողը տեղադրել բոլորովին այլ տեղ։ Հեռավոր դինամիկ փոխանցումը բացում է SOCKS պորտը հեռավոր հոսթի վրա և յուրաքանչյուր կապ սկսում է ձեր տեղական SSH հաճախորդից, որը կրում է ձեր նոթբուքի հաստատված VPN ուղին։ Pi-ն ստանում է սահմանափակ վստահված սերվեր؛ այն չի ժառանգում ձեր թունելը կամ ձեր արտոնությունները։

Լսողը և կապը սկսող կողմը կարող են տարբեր լինել

Սովորական ssh -D 1080-ը լսողը գործարկում է ձեր սեփական մեքենայի վրա և այնտեղից ուղարկում կապերը։ Հեռավոր դինամիկ փոխանցումը շրջում է դա՝ լսողը հայտնվում է հեռավոր հոսթի վրա, և յուրաքանչյուր կապ, որը նա ընդունում է, բացվում է տեղական կողմից։ OpenSSH հաճախորդի ձեռնարկը փաստագրում է -R-ը առանց հաստատուն նպատակակետի հենց որպես այս SOCKS4/5 դասավորություն։

Նոթբուքից աջակցվող հրամանն այսպիսի տեսք ունի, որտեղ հաշիվը, հոսթերը և պորտը համարվում են տեղապահներ:

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

Երեք մանրամասն օգտակար աշխատանք են կատարում այնտեղ։ -S none-ը մեկուսացնում է սեսիան ընդհանուր կառավարման մաստերից, ExitOnForwardFailure-ը արագ ձախողվում է՝ ձեզ կիսաբաց սեսիայով թողնելու փոխարեն, իսկ PermitRemoteOpen-ը սահմանափակում է, թե ինչի կարող է հասնել հեռավոր լսողը։ Օգտագործեք լիազորված Pi հաշիվ և ստուգեք հոսթի բանալին նախքան սրանից որևէ բան ավելացնելը։

Ինչ է իրականում բացահայտում հեռավոր լսողը

Ստուգեք սերվերի փոխանցման քաղաքականությունը նախքան լսողին ապավինելը։ GatewayPorts no-ով հեռավոր փոխանցումը մնում է կապված loopback-ին, և դա է այն ազդեցությունը, որը դուք ուզում եք։ Wildcard փոխանցում պարտադրող սերվերը հրապարակում է նույն պորտը բոլոր ինտերֆեյսներում, ինչը անձնական վստահված սերվերը դարձնում է տեղական ցանցի համար հասանելի բան։

Loopback-ը նույնպես օգտվողական սահման չէ։ Pi-ի վրա մեկ այլ գործընթաց կարող է միանալ 127.0.0.1:1080-ին, եթե գիտի պորտը, ուստի Pi-ի տեղական հաշիվները և այն ամենը, ինչ աշխատում է դրա վրա, ձեր մուտքի ձևավորման մասն են։ Սա պատճառ է նպատակակետերի ցանկը նեղ պահելու, ոչ թե քաղաքականության ստուգումը բաց թողնելու։

Պահեք թույլատրված նպատակակետը կոնկրետ այն հավելվածի համար, որին փորձում եք հասնել։ Այն անսահմանափակ փոխանցումով փոխարինելը, որպեսզի աշխատի անկապ ծրագիր, ուղին շատ ավելի լայն է դարձնում, քան այն խնդիրը, որով սկսել եք։ Նպատակակետերի ցանկը նաև գրանցում է, թե ինչի համար էր սեսիան, ինչը օգնում է նրան, ով հետագայում կաուդիտի այն։ Գրեք այն ձեր օգտագործած հաշվի կողքին։

Մեկ հավելված անցկացրեք վստահված սերվերով

Pi-ի վրա վստահված սերվերը հասկացող հաճախորդն այնուհետև կարող է ուղարկել հարցումը։ socks5h նախածանցը նպատակակետի անունը հանձնում է վստահված սերվերին, ուստի որոնումն ու կապը երկուսն էլ տեղի են ունենում նոթբուքի կողմում, և այն համապատասխանում է PermitRemoteOpen-ում նշված նպատակակետին:

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

Պահեք սովորական սերտիֆիկատի վավերացումը և հավելվածի սեփական նույնականացումը։ Վստահված սերվերը փոխում է, թե որտեղ է ստեղծվում TCP կապը; այն անվտանգ չի դարձնում առանց նույնականացման ծառայությունը և ինքնաստորագրված վերջնակետը չի դարձնում վստահելի։

Նոթբուքը դեռ կարիք ունի իր ուղուն և լուծիչի հասանելիությանը ինչպես SSH սերվերին, այնպես էլ հավելվածին։ Նրա SSH հաճախորդի երթևեկությունը պետք է ընտրվի հաստատված VPN քաղաքականությամբ, և split-tunnel բացառությունը կարող է այդ երթևեկությունն ուղարկել ձեր փորձարկածից տարբեր ուղով։

Ապացուցեք ուղին և փակեք այն

Հաստատեք, որ լսողը գոյություն ունի այնտեղ, որտեղ սպասում եք, և որ պատասխանում է միայն նախատեսված նպատակակետը:

$ 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-ը կարող է ապացուցել, որ փոխանցումը հաստատվել է, և այնուամենայնիվ չի կարող հավաստել, որ հավելվածի մուտքը հոսանքն ի վար հաջողվում է։ Փորձարկեք հավելվածը, ոչ միայն պորտը։ Լսողը, որը ընդունում է, ապա ձախողում ամեն հարցում, սովորաբար նշանակում է, որ նպատակակետի անունը կամ նոթբուքի ուղին սխալ է, ոչ թե թունելը ձախողվել է։

Այս դասավորությունը տեղափոխում է միայն TCP։ UDP-ն, ICMP-ն և վստահված սերվերի կարգավորումներն անտեսող ծրագրերը մնում են դրանից դուրս, և փոխանցումն ավարտվում է այն պահին, երբ ավարտվում է SSH սեսիան։ Կանգնեցրեք այդ սեսիան, երբ ավարտեք, և հեռացրեք հավելվածին ավելացրած վստահված սերվերի կարգավորումը։

Մշտական հասանելիության համար օգտագործեք փոխարենը ցանցի սեփականատիրոջ աջակցվող գրանցումը կամ կառավարվող դարպասը։ Հակադարձ վստահված սերվերը սխալ գործիք է VPN-ի սարքային կամ ռեսուրսային սահմանափակումները շրջանցելու համար՝ դրանց ներսում օգտագործելով՝ այն պարզապես մեկ լիազորված հավելվածային ուղի է՝ հստակ սահմաններով։