NetworkManager-ssh-ը ցույց է տալիս միացված, բայց ոչինչ չի երթուղվում
Ցուցիչը միայն ապացուցում է, որ կառավարվող SSH հարաբերությունը գոյություն ունի։ Ստուգեք՝ պլագինը թունելային սարք է կառուցել, թե փոխանցումների հավաքածու, ապա ստուգեք հավելվածի ուղին։
Ընտրացանկը ցույց է տալիս SSH միացումը որպես ակտիվ, հոսթի բանալին ընդունվել է, և դիտարկիչը դեռ չի հասնում այն ամենին, ինչին պետք է հասներ։ Սա հակասություն չէ, որովհետև NetworkManager-ssh պրոֆիլը կարող է նույն հոսթից և բանալուց ստանալ երկու բոլորովին տարբեր արդյունք՝ փաթեթներ կրող թունելային սարք կամ փոխանցումների հավաքածու, որոնք կարող են օգտագործել միայն որոշ հավելվածներ։ Ցուցիչը հաղորդում է, որ կառավարվող SSH հարաբերությունը գոյություն ունի։ Այն երբեք չի հաղորդում, թե երկուսից որն եք ստացել։
Երկու արդյունք մեկ ընտրացանկի կետի հետևում
Երկու ռեժիմներն էլ նույնականացնում են նույն կերպ, և հենց դրա համար են շփոթում։ Պրոֆիլը նույն կերպ, նույն հավատարմագրերով ընտրելը կարող է ձեզ թողնել ինտերֆեյսով, որով կարելի է երթուղել, կամ լսող սոքեթով, որի մասին պետք է տեղեկացնել մեկ հավելվածի։
Սկսեք որոշելով, թե առաջադրանքն իրականում որ արդյունքի կարիքն ունի։ Ամբողջ ենթացանցի հասանելիության պահանջը սարք է պահանջում։ Հեռավոր հոսթի մեկ ծառայությունը պահանջում է փոխանցում, և դրա համար թունել կառուցելը սովորաբար ավելի շատ երթուղային աշխատանք է ստեղծում, քան խնդիրը արժանի էր։
Ինչ պետք է ունենա յուրաքանչյուր ռեժիմ մինչև աշխատելը
Նախագիծը փաստագրում է երկու ռեժիմները, և նախապայմաններն այնքան տարբեր են, որ բացակայողը պրոտոկոլի ձախողում է թվում, ոչ թե դիզայնի ընտրություն։
| Mode | What must exist | What still has to be true |
|---|---|---|
| Tunnel device | Compatible TUN/TAP arrangement on both ends, permission, addressing | A route policy that actually sends the intended prefixes into it |
| Forwarding only | A chosen SOCKS, local-forward or remote-forward listener | A permitted destination path on the far side |
Ուշադիր կարդացեք աջ սյունակը, որովհետև այնտեղ են ավարտվում այս դեպքերի մեծ մասը։ Անգամ կատարյալ կառուցված թունելային սարքը ծածկում է միայն այն, ինչ երթուղումը ուղարկում է դրա մեջ, և անգամ կատարյալ փոխանցումը օգնում է միայն այն հավելվածներին, որոնց ասվել է օգտագործել այն։
Կեղծ ինտերֆեյսը թունել չէ
Փոխանցման ռեժիմում պլագինը փաստագրում է կեղծ ինտերֆեյս, որը ստեղծվում է միացման մոդելը բավարարելու համար։ Այն գոյություն ունի, որպեսզի կառավարիչն ունենա ինչ-որ բան, որին կցի վիճակը։ Այն չի փոխադրում կամայական հավելվածային փաթեթներ դեպի հեռավոր ցանց, և դրա առկայության մեջ ոչինչ չի ենթադրում, որ IP երթուղումը փոխվել է։
Նախագծի ամբողջական թունելի օրինակները վերաբերում են OpenSSH-ի թունելային սարքի աջակցությանը, ուստի պիտակի մեջ թունել բառը նկարագրում է հնարավորություն, ոչ թե ձեր փաստացի քաղաքականությունը։ Ստուգեք, թե ինչ կանի միջուկը, ոչ թե ինչպես է կոչվում պրոֆիլը։
nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"Ապա համապատասխանեցրեք արդյունքը հավելվածին։ SOCKS հասկացող ծրագիրը պետք է կարգավորվի օգտագործելու վահանակը։ Տեղական փոխանցման սպառողը պետք է ուղղորդվի իր լսողին։ Նրանցից ոչ մեկը ինքնուրույն չի հայտնաբերում փոխանցումը, և ոչ մեկին չի օգնում կանաչ դարձած միացման ցուցիչը։
Պատրաստեք հեռավոր կողմը՝ փոխարենը այն պարտադրելու
Սովորական SSH հաշիվը կարող է նույնականացվել առանց հեռավոր թունելային սարք բարձրացնելու թույլտվության։ Նախագիծը փաստագրում է առանց root-ի ուղի, որտեղ ադմինիստրատորը նախապես ստեղծում է սարքը տվյալ օգտագործողի համար, և հաճախորդն այնուհետև ընտրում է համապատասխան համարը։
Նման դասավորությունը համակարգում է պահանջում սերվերի թունելային քաղաքականության և հեռավոր ցանցում հասցեավորումը տնօրինողի հետ։ Սարքի ստեղծումն ինքնին չի տալիս ռեսուրսների երթուղիները, փոխանցման թույլտվությունները կամ վերադարձի ուղին, և դրանցից ոչինչ չի գալիս այն պատճառով, որ օրինակի կարգավորումը համոզիչ էր թվում։
Ինչ չպետք է անեք՝ օրինակն աշխատեցնելու համար միացնել անսահմանափակ փոխանցումը կամ հեռավոր root մուտքը։ Այնտեղ, որտեղ օպերատորն է տնօրինում հեռավոր ցանցի կարգավորումը, օգտագործեք աջակցվող դասավորությունը՝ այդ հրահանգները թողնելու այդ սեփականատիրոջը, և խուսափեք երկրորդ օգնականից, որը միացման կտրվելիս վերականգնում է հակասական հասցեներ։
Նույնականացման համատեքստը, և ինչ գրել տոմսում
Նույնականացումն ունի իր համատեքստը։ Պլագինը փնտրում է օգտագործողի սեանսին կապված SSH գործակալ և պահանջում է, որ նշանակակետային հոսթը հայտնի լինի, ուստի մեկ տերմինալում աշխատող բանալին ավտոմատ չի դառնում տեսանելի կառավարչի նույնականացման ուղուն։ Թույլ տվեք, որ հոսթի բանալին գրանցվի և ստուգվի հաստատված ընթացակարգով, փոխարենը ստուգումը անջատելու։
Աջակցության համար գրանցեք չորս բան՝ պլագինը և տարբերակը, ընտրված ռեժիմը, նախատեսված հեռավոր ինքնությունը և այն ինտերֆեյսը կամ լսողը, որը պետք է հայտնվեր։ Ապա ուղղակիորեն ստուգեք հավելվածի մուտքի կետը։ Միացված ցուցիչը աշխատող թեստի հետ միասին ապացույց է։ Միայն միացված ցուցիչը հայտարարություն է SSH-ի մասին, ոչ այն երթուղման կամ ռեսուրսի թույլտվության մասին, որը փորձում էիք ստանալ։