Ձեր սարքը գտնվում է օպերատորի NAT-ի հետևում, այն կարող է բացել ելքային միացումներ և աշխատեցնում է SSH սերվեր, որին ոչ ոք չի հասնում։ Եկող հարցումը սովորաբար ձևակերպվում է որպես «տվեք նրան VPN», ինչը մի պատասխան է մի քանիսից։ Նախքան ընդունելը որոշեք՝ ձեզ պետք է մեկ վարչական TCP պորտ, թե՞ երթուղավորված ուղի ամբողջ ենթացանցին՝ որովհետև դրանք տարբեր նախագծեր են տարբեր ազդեցությամբ։

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

Երեք պայման, որոնք որոշում են ընտրությունը

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

ConditionReverse tunnel fitsSomething else is needed
How many services must be reachable?One, or a small fixed set on loopbackAnything that needs many ports or dynamic discovery
Who connects, and how are they authenticated?Named administrators with their own hub accountsThird parties, or anything needing per-flow audit you do not control
Does the device's own LAN need to be reachable?NoYes, so a routed VPN or a managed platform is the honest answer

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

Հանգույցի կողմը՝ սահմանափակ ռելե հաշիվ

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

Match User relay-dev-7
    AuthenticationMethods publickey
    PubkeyAuthentication yes
    AllowTcpForwarding remote
    PermitListen 127.0.0.1:21022
    GatewayPorts no
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

MaxSessions 0 հետաքրքիր տողն է։ Այն մերժում է shell և ենթահամակարգերի սեսիաները՝ միաժամանակ թույլ տալով սարքին անհրաժեշտ փոխանցումը, այնպես որ գողացված բանալին չի կարող վերածվել ինտերակտիվ մուտքի։ PermitListen ամրագրում է հանգույցի կողմի լսողի հասցեն և պորտը, և GatewayPorts no այն պահում է loopback-ի վրա՝ փոխարենը չբացելով ցանցին, որտեղ գտնվում է հանգույցը։

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

Սարքի կողմը՝ փոխանցում, որը բարձր ձայնով ձախողվում է

Սարքը բացում է միացումը և պահանջում լսողը։ Փաստարկի երկու հասցեները -R տարբեր իմաստներ ունեն, և դրանք ձախից աջ կարդալը ամենաարագ ձևն է հիշելու, թե որն է որը։

ssh -NT \
    -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=30 \
    -o ServerAliveCountMax=3 \
    -R 127.0.0.1:21022:127.0.0.1:22 \
    [email protected]

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

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

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

Ադմինիստրատորի մուտքը հանգույցի միջոցով

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

ssh -J [email protected] -o HostKeyAlias=device-7 \
    -p 21022 [email protected]

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

Վերցրեք կյանքի ցիկլի սեփականությունը

Գործարկեք սարքի հրամանը գործընթացների կառավարչի ներքո՝ ուղիղ մեկ ակտիվ օրինակով և ձեր գիտակցաբար ընտրած վերագործարկման քաղաքականությամբ։ Keepalive պարամետրերը հայտնաբերում են մեռած գործընկերոջը․ դրանք չեն հարություն տալիս դուրս եկած գործընթացին։

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

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

Առնչվող հոդվածներ