Հասանելիություն միայն VPN-ով հասանելի HTTPS կայքին SSH փոխանցման միջոցով

Մի մեքենա արդեն ունի հաստատված VPN հասանելիություն, երկրորդ մեքենային անհրաժեշտ է ուղիղ մեկ մասնավոր HTTPS ծառայություն, և տեղական SSH փոխանցումը կարող է կամրջել այդ բացը՝ առանց երկրորդ մեքենային թունել տալու։ Փոխանցումը կրում է մեկ TCP նպատակակետ՝ ամբողջ ցանցի փոխարեն, և հենց այդ սահմանափակումն է էությունը։ Անցեք ստորև նշված հինգ քայլերը հերթականությամբ, որովհետև յուրաքանչյուրը ձախողվում է տարբեր պատճառով, և ավելի ուշ քայլը չի կարող փրկել ավելի վաղ բացը։ Եթե որևէ նախապայման բացակայում է, այս ձևավորումը այն չի լուծում, և հրամանների ոչ մի կարգավորում չի օգնի։

Քայլ առաջին. հաստատեք երեք նախապայմանները

Երեք բան պետք է արդեն ճիշտ լինի, նախքան որևէ հրաման նշանակություն կունենա։ Անհրաժեշտ է թույլտվություն առաջին մեքենան որպես փոխանցող հոսթ օգտագործելու, դրան աշխատող SSH հասանելիություն և սերվերի քաղաքականություն, որը թույլատրում է նախատեսված նպատակակետը։ Ֆայլերի փոխանցման համար ստեղծված SSH հաշվում փոխանցումը կարող է անջատված լինել, և փոխանցումը թույլատրող սերվերը դեռ կարող է սահմանափակել, թե որ նպատակակետերն են հասանելի դրա միջոցով։ Հարցրեք փորձարկելուց առաջ, որովհետև գործընկերոջ աշխատանքային կայանը առանց համաձայնության որպես ցատկող կետ օգտագործելը քաղաքականության խնդիր է, նույնիսկ երբ հրամանը կատարյալ աշխատում է։

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

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Քայլ երկրորդ. կապեք loopback պորտը և պահեք նստաշրջանը կենդանի

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

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

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Քայլ երրորդ. պահպանեք HTTPS անունը, երբ վարդակը տեղական է

https://127.0.0.1:9443/-ին այցելելը փոխում է TLS սերվերի անունը և հավելվածի լիազորությունը։ portal.lab.example-ի համար թողարկված վկայագիրը չի վավերացվի loopback հասցեի դեմ, և առաջացած սխալը կարծես կոտրված վկայագիր լինի, ոչ թե փոխանցման կարճուղի։ Հրամանի տողի փորձարկման համար պահպանեք իրական URL-ը և փոխեք միայն վարդակի նպատակակետը։ Դա է անում --connect-to-ը, և curl ձեռնարկը փաստագրում է ստորև օգտագործվող չորս դաշտի ձևը։

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

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

Քայլ չորրորդ. իմացեք, թե ինչ չի ծածկում մեկ փոխանցում

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

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

Քայլ հինգերորդ. մաքրեք և գրանցեք

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

Գրեք ցատկող հոսթը, փոխանցված նպատակակետը, տեղական պորտը և թե ով է հաստատել պայմանավորվածությունը։ Փոխանցումը, որը գոյություն ունի միայն ինչ-որ մեկի shell պատմության մեջ, մեկ վերագործարկում է հեռու կրկնվող հետաքննությունից, և հաջորդ մարդը չի իմանա, թե երեք նախապայմաններից որն է արդեն ստուգվել։