Ինչ հավելվածային երթևեկ է իրականում տանում SSH փոխանցումը։

Տերմինալը միանում է, հուշումը հայտնվում է, և բոլորը համաձայն են, որ SSH մուտքը աշխատում է։ Այնուհետև նոութբուքի տվյալների բազայի հաճախորդը դեռ չի կարողանում հասնել մասնավոր սերվերին, և մեղադրվում է սեսիան։ Կառուցվածը պատյան էր, և դա SSH-ի առաջարկած չորս բոլորովին տարբեր միջերեսներից մեկն է։ Նախ անվանեք միջերեսը, ապա ստուգեք, որ հավելվածն իսկապես օգտագործում է այն։ Հերթականությունը կարևոր է, որովհետև յուրաքանչյուր միջերես ձախողվում է իր ձևով։

Անվանեք միջերեսը, նախքան ինչ-որ բան համեմատելը

OpenSSH հաճախորդի ձեռնարկը տարբերում է չորս մեխանիզմ, որոնք հեշտ է շփոթել։ Պատյանը կամ հեռավոր հրամանը կատարվում է SSH սերվերի վրա։ Տեղական փոխանցումը բացում է լսող սոկետ հաճախորդի վրա և հետագա կապը հաստատում է հեռավոր կողմից։ Հեռավոր փոխանցումը անում է հակառակը՝ լսելով սերվերի կողմում։ Դինամիկ փոխանցումը SOCKS վերջնակետ է տրամադրում այն ծրագրերին, որոնք գիտեն ինչպես օգտագործել այն։

• Պատյան: ծրագիրը աշխատում է հեռավոր մեքենայի վրա, տեղում ոչինչ չի լսում։
• Տեղական փոխանցում: ձեր նոութբուքն ունի պորտ, հեռավոր սերվերը կատարում է ելքային կապը։
• Հեռավոր փոխանցում: հեռավոր կողմն ունի պորտ, երթևեկը վերադառնում է ձեզ մոտ։
• Դինամիկ: SOCKS վստահված սերվեր հաճախորդի վրա, օգտագործում են միայն վստահված սերվերը հասկացող հավելվածները։

Սրանցից ոչ մեկը երթուղի չի տեղադրում։ Ծրագիրը, որը անտեսում է վստահված սերվերի կարգավորումները, կամ խոսում է UDP, կամ ինքն է լուծում անունները, չի ազդվում ակտիվ SSH սեսիայից։ Սա SSH-ի սխալ չէ, դա ձեր ընտրած միջերեսի շրջանակն է։

Տեղական, հեռավոր և դինամիկ փոխանցումները տարբերվում են նրանով, թե ով է լսում

Տարբերությունը, որը որոշում է դեպքերի մեծ մասը, այն է, թե ով է տիրապետում լսող սոկետին։ Տեղական փոխանցման դեպքում լսում է հաճախորդը, և հեռավոր ծայրը հավաքում է նպատակակետը, այդ պատճառով նպատակակետի հասցեն լուծվում է սերվերի տեսանկյունից։ Հեռավոր փոխանցման դեպքում լսում է սերվերը, և կապը տարվում է ձեր կողմ, և այդպես դուք բացահայտում եք տեղական ծառայություն առանց այն ուղղակիորեն հրապարակելու։

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

Առաջին հրամանը կապում է 5432 պորտը նոութբուքի վրա և փոխանցում այն տվյալների բազային այնպես, ինչպես այն երևում է բաստիոնից։ Երկրորդը ստեղծում է SOCKS վստահված սերվեր 1080 պորտի վրա։ Երրորդ հրամանը հաստատում է, թե որ գործընթացներն են իրականում լսում, և դա միակ ապացույցն է, որ փոխանցումը գոյություն ունի, այլ ոչ թե լուռ ձախողվել է պորտի բախման պատճառով։

Դինամիկ փոխանցումը արժանի է իր սեփական նախազգուշացմանը. այն ընդգրկում է միայն այն հավելվածները, որոնք հարգում են SOCKS-ը։ Դիտարկիչը կարելի է ուղղել դրան, հրամանային տողի գործիքին կարելի է ասել օգտագործել այն, բայց սեփական կապի փաթեթ ունեցող տվյալների բազայի դրայվերը սովորաբար չի կարող։ Այն ենթադրությունը, որ մեքենայի յուրաքանչյուր ծրագիր այժմ օգտագործում է թունելը, այս ամբողջ ոլորտի ամենատարածված սխալն է։

Թունելային սարքի ռեժիմը միակ իրական ցանցային բացառությունն է

OpenSSH-ը նաև աջակցում է -w թունելային սարքի փոխանցմանը, որը TCP լսողի փոխարեն անցկացնում է կետ-կետ միջերես։ Դա իսկական ցանցային թունել է, և այն կարգավորվում է դիտավորյալ, ոչ թե պատյան բացելու կողմնակի ազդեցություն է։

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Այն պահանջում է համապատասխան միջերեսների համարներ երկու ծայրերում, ճիշտ կարգավորում սերվերի վրա և բավարար արտոնություն հաճախորդի վրա սարքը ստեղծելու համար։ Այն նաև պահանջում է հասցեավորման և երթուղավորման պլան, որովհետև մերկ միջերեսը որևէ քաղաքականություն չի կրում այն մասին, թե որ նպատակակետերը պետք է օգտագործեն այն։

Նույնիսկ այդ դեպքում թունելը ավարտվում է հեռավոր սերվերում։ Ինչ պաշտպանություն էլ տրամադրել է SSH փոխադրումը, այն ավարտվում է այնտեղ, և հետագա կապը առանձին ցատկ է։ VPN դարպասն ունի սահմանի նույն ձևը, այդ պատճառով համեմատությունը պետք է լինի շրջանակի և ավարտի մասին, ոչ թե այն մասին, թե որ գործիքն է ավելի ուժեղ։ Այդ սահմանը բարձրաձայն անվանելը նաև լուծում է վեճը այն մասին, թե արդյոք թունելը «գաղտնագրում է ամեն ինչ», որովհետև ակնհայտորեն չի գաղտնագրում։

Ստուգեք, որ ձեր հավելվածը օգտագործում է ձեր կառուցած միջերեսը

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

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

Առաջին հրամանը հարցում է ուղարկում SOCKS վերջնակետով՝ սերվերի անունը հեռավոր լուծելով, իսկ երկրորդը փորձարկում է փոխանցված տվյալների բազայի պորտը, երբ TLS-ը դեռ պարտադիր է։ Գործարկեք նույն փորձարկումները կանգնեցված փոխանցմամբ՝ համոզվելու համար, որ դրանք ձախողվում են, որովհետև երկու ձևով էլ անցնող փորձարկումը երբեք չի օգտագործել թունելը։

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