એક ઉપકરણ માટે રિવર્સ SSH: લૂપબેક શ્રોતા કે રાઉટેડ VPN?

એવા ઉપકરણ માટે એક જ મેનેજમેન્ટ પોર્ટ જે ફક્ત બહાર જ ડાયલ કરી શકે. ત્રણ શરતો નક્કી કરે છે કે રિવર્સ ટનલ પૂરતી છે કે તમારે ખરેખર રાઉટેડ પાથની જરૂર છે.

તમારું ઉપકરણ કેરિયર NAT પાછળ બેઠું છે, તે બહારમુખી જોડાણો ખોલી શકે છે, અને તે એવો SSH સર્વર ચલાવે છે જ્યાં કોઈ પહોંચી શકતું નથી. જે વિનંતી આવે છે તે સામાન્ય રીતે "તેને VPN આપો" તરીકે કહેવાય છે, જે ઘણા જવાબોમાંથી એક છે. તેને સ્વીકારતા પહેલા નક્કી કરો કે તમારે એક વહીવટી TCP પોર્ટ જોઈએ છે કે આખા સબનેટ સુધીનો રાઉટેડ પાથ, કારણ કે તે અલગ એક્સપોઝરવાળા અલગ પ્રોજેક્ટ છે.

રિવર્સ ટનલ સાંકડા સંસ્કરણનો સારો જવાબ આપે છે. ઉપકરણ તમારા હબ પર ડાયલ કરે છે, હબને લૂપબેક પોર્ટ પર સાંભળવા કહે છે, અને તે પોર્ટને પોતાની 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 રસપ્રદ લીટી છે. તે શેલ અને સબસિસ્ટમ સત્રો નકારે છે જ્યારે ઉપકરણને જરૂરી ફોરવર્ડિંગની મંજૂરી આપે છે, તેથી ચોરાયેલી કીને ઇન્ટરેક્ટિવ લોગિનમાં ફેરવી શકાતી નથી. PermitListen હબ બાજુના શ્રોતાનું સરનામું અને પોર્ટ પિન કરે છે, અને GatewayPorts no તેને હબ જે નેટવર્ક પર છે તેના માટે ખોલવાને બદલે લૂપબેક પર રાખે છે.

રીલોડ કરતા પહેલા અસરકારક ગોઠવણીનું પરીક્ષણ કરો, અને તે કરતી વખતે બીજું સત્ર ખુલ્લું રાખો. 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 સેવા પછી સ્વસ્થ છે કે નહીં તે વિશે તે કંઈ કહેતું નથી, તેથી તેને પ્રોસેસ મેનેજર અને ક્યારેક ખરેખર જોડાણ પરીક્ષણ સાથે જોડો.

વધારાના હોપ ટાળવા માટે લૂપબેક સાંભળવાના સરનામાને ક્યારેય વાઇલ્ડકાર્ડથી બદલશો નહીં. એ એક જ ફેરફાર મેનેજમેન્ટ પાથ અને જાહેરમાં પહોંચી શકાય તેવા પોર્ટ વચ્ચેનો તફાવત છે, અને તે સામાન્ય રીતે ડિબગિંગ દરમિયાન થાય છે અને પછી રહી જાય છે. જો સહકર્મી હબ દ્વારા પોર્ટ સુધી ન પહોંચી શકે, તો બાઇન્ડ પહોળું કરવાને બદલે જમ્પ ગોઠવણી સુધારો. આ ડિઝાઇનની આખી સુરક્ષા દલીલ લૂપબેક છે.

હબ દ્વારા વહીવટકર્તા પ્રવેશ

હબ પર સામાન્ય એકાઉન્ટ ધરાવતો વહીવટકર્તા તેના દ્વારા ફોરવર્ડ કરેલા પોર્ટ પર જઈ શકે છે. રિલે એકાઉન્ટ આ માટે વપરાતું નથી, અને તેમને અલગ રાખવાનો અર્થ એ જ છે.

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

તમે પસંદ કરેલા ઉપનામ હેઠળ ઉપકરણની હોસ્ટ કી ચકાસો, કારણ કે તે કી સાંકળના અંતે ઉપકરણને ઓળખે છે અને ટનલ ફક્ત પરિવહન છે. છેડાથી છેડા સુધીનું લોગિન હજી પણ બંને છેડાને પ્રમાણિત કરે છે; વિભાજિત હબ પર સમાપ્ત થતી ટનલ તેને પોતાની જાતે વિશ્વસનીય પાથ બનાવતી નથી.

જીવનચક્રની માલિકી લો

ઉપકરણનો આદેશ પ્રોસેસ મેનેજર હેઠળ બરાબર એક સક્રિય ઇન્સ્ટન્સ અને જાણી જોઈને પસંદ કરેલી રીસ્ટાર્ટ નીતિ સાથે ચલાવો. કીપઅલાઇવ વિકલ્પો મૃત સાથીને ઓળખે છે; તેઓ બહાર નીકળેલી પ્રોસેસને ફરી જીવિત કરતા નથી.

પછી નિવૃત્તિ પ્રક્રિયા લખો. દરેક ઉપકરણને તેનું પોતાનું શ્રોતા અને પોતાની કી મળે છે, તેથી ડિકમિશન કરવાનો અર્થ તે એકાઉન્ટ રદ કરવું અને તે કી દૂર કરવી, આખા ફ્લીટમાં વહેંચાયેલી ગુપ્તતા ફેરવવી નહીં.

છેલ્લે યાદ રાખો કે લૂપબેક તમને શું આપે છે. તે નેટવર્ક એક્સપોઝર મર્યાદિત કરે છે અને વિભાજિત હબ પરના અન્ય સ્થાનિક વપરાશકર્તાઓ વિશે કંઈ કરતું નથી, તેથી હબની પોતાની પ્રવેશ નીતિ હજી પણ સાચી હોવી જોઈએ. sshd_config સંદર્ભ ઉપર વપરાયેલા દરેક વિકલ્પનું દસ્તાવેજીકરણ કરે છે, અને તેમાંથી કોઈપણને પહોળું કરતા પહેલા ફોરવર્ડિંગ વિભાગો પૂરા વાંચવા યોગ્ય છે.

સંબંધિત લેખો