VPN દ્વારા રિમોટ SSH: ટનલ શું કરતું નથી
VPN એ SSH સર્વરને પહોંચપાત્ર બનાવે છે અને તેથી વધુ કંઈ નહીં. ત્રણ શરતો નક્કી કરે છે કે તે યોગ્ય છે કે નહીં, અને નિષ્ફળતાનો તબક્કો જણાવે છે કે કયો સ્તર દોષિત છે.
VPN એ SSH સર્વરને ખાનગી માર્ગ આપે છે અને પોર્ટ 22 પર જાહેર શ્રોતાની જરૂર દૂર કરે છે. તે હોસ્ટને પ્રમાણિત કરતું નથી, વપરાશકર્તાને અધિકૃત કરતું નથી અને કયા ખાતાં લોગ ઇન કરી શકે તે નક્કી કરતું નથી. તે SSH નું કામ જ રહે છે. VPN એ સર્વર સુધી પહોંચવાનો યોગ્ય માર્ગ છે કે નહીં તે ત્રણ શરતો પર આધાર રાખે છે, અને ટનલ ફક્ત સંભવિત જવાબોમાંનો એક છે.
ટનલ શું બદલે છે અને SSH હજી શું નક્કી કરે છે
ટનલ પહોંચ બદલે છે: કયા સરનામાં સુધી પહોંચી શકાય છે, અને ક્યાંથી. TCP જોડાણ પહોંચ્યા પછી શું થાય છે તે તે બદલતું નથી, જ્યાં સર્વર હોસ્ટ કી રજૂ કરે છે અને વપરાશકર્તાની ઓળખ માંગે છે.
બે સ્તરોને તમારા મનમાં અને તમારા દસ્તાવેજીકરણમાં અલગ રાખો. VPN લોગિન સાબિત કરે છે કે કોણ નેટવર્ક વાપરી શકે છે. તે લક્ષ્ય પર કયા ખાતાં છે તે વિશે કંઈ કહેતું નથી, અને તે દરેક પહોંચપાત્ર મશીનમાં સાઇન ઇન કરવાની પરવાનગી નથી.
નિષ્ફળતાના પ્રકારો પણ અલગ છે, અને તે જ ઘટનાના સમયે વિભાજનને ઉપયોગી બનાવે છે.
ત્રણ શરતો જે પ્રવેશ મોડેલ નક્કી કરે છે
પ્રથમ, શું સર્વર તમારા નેટવર્કની બહારના લોકો માટે પહોંચપાત્ર હોવું જરૂરી છે? જો નહીં, તો ખાનગી માર્ગ અને એક બેસ્ટિયન અથવા એક મેશ નાની રચના છે. બીજું, શું ગ્રાહક વસ્તી ખરેખર VPN ક્લાયન્ટ ચલાવી શકે છે, જેમાં મર્યાદાઓ સાથેના વ્યવસ્થાપિત ઉપકરણો પરના લોકોનો પણ સમાવેશ થાય છે?
ત્રીજું, તમારે સેવા દીઠ નિયંત્રણ જોઈએ છે કે વપરાશકર્તા દીઠ નિયંત્રણ? VPN નેટવર્ક પહોંચ આપે છે; SSH ખાતા પ્રવેશ આપે છે. જો આવશ્યકતા એ હોય કે કોન્ટ્રાક્ટર એક હોસ્ટ સુધી પહોંચે અને બીજું કંઈ નહીં, તો તે અધિકૃતિની આવશ્યકતા છે અને ફક્ત ટનલ તેને વ્યક્ત કરી શકતું નથી.
તે ત્રણનો જવાબ આપો અને મોડેલ પોતાને પસંદ કરે છે. તેમને છોડી દો અને તમે ક્લાયન્ટ રોલઆઉટ ટાળવા માટે SSH ને જાહેરમાં ઉજાગર કરીને અંત કરશો.
SSH ને દોષ આપતા પહેલાં ખાનગી માર્ગની ખાતરી કરો
મંજૂર VPN સાથે કનેક્ટ કરો અને લક્ષ્યનું દસ્તાવેજીકૃત ખાનગી નામ અથવા સરનામું વાપરો. પછી પસંદ કરેલો માર્ગ, ગેટવેની પરવાનગી અને ક્લાયન્ટ તરફનો પરત માર્ગ તપાસો. યોગ્ય રીતે ઉકેલાયેલું નામ એ પુરાવો નથી કે સરનામું ઇચ્છિત ટનલ લે છે, કારણ કે એકબીજા પર વળેલા સ્થાનિક અને દૂરના પ્રીફિક્સ વિનંતીને સંપૂર્ણપણે બીજે ક્યાંક મોકલી શકે છે. તે તફાવત રનબુકમાં લખવા યોગ્ય છે.
જો જોડાણ ક્યારેય પહોંચતું નથી, ખાતરી કરો કે સર્વર તમે અપેક્ષા રાખો છો તે ઇન્ટરફેસ પર સાંભળી રહ્યું છે અને તેનો હોસ્ટ ફાયરવોલ તે સ્રોતને મંજૂરી આપે છે જે તે ખરેખર જુએ છે. ગેટવે NAT તે સ્રોતને ફરીથી લખી શકે છે, તેથી ક્લાયન્ટના ટનલ સરનામા માટે લખાયેલી મંજૂરી સૂચિ ક્યારેય મેળ ખાતી નથી.
તે અસંગતિ VPN પરની સૌથી સામાન્ય સ્વ-નિર્મિત SSH નિષ્ફળતા છે.
સંયુક્ત ભૂલ નહીં, નિષ્ફળતાનો તબક્કો વાંચો
ત્રણ તબક્કા ત્રણ અલગ સંદેશા ઉત્પન્ન કરે છે, અને તેમાંથી ફક્ત એક જ ઓળખપત્રો વિશે છે.
| Stage | What you see | What it points at |
|---|---|---|
| Before the connection | Timeout, no route | Tunnel, route or gateway permission |
| Connection refused | Immediate reset | Nothing listening, or a host firewall rejecting |
| Authentication | Permission denied after a prompt | User, key or server policy |
VPN અને SSH ઓળખપત્રો એકસાથે રીસેટ કરવાને બદલે ચોક્કસ ભૂલ અને સર્વરનું પોતાનું લોગ વાપરો. બંનેને રીસેટ કરવું એ પાંચ મિનિટની નિદાનને બે દિવસની ઓળખ ઘટનામાં ફેરવવાનો માર્ગ છે.
વિગતવાર આઉટપુટ બતાવે છે કે તમે કયા તબક્કે પહોંચ્યા:
ssh -vv [email protected]હોસ્ટ કી અને અધિકૃતિ અકબંધ રાખો
હોસ્ટ કીને ઇચ્છિત વિશ્વસનીય પ્રક્રિયા દ્વારા માન્ય કરો, ખાસ કરીને સર્વર બદલ્યા પછી. અણધારી બદલાયેલી-કી ચેતવણી એ એકમાત્ર સંદેશ છે જેને તમે ફક્ત એટલા માટે અવગણવો નહીં જોઈએ કે VPN જોડાયું છે, કારણ કે ખાનગી ટનલ લક્ષ્યને તમે વિચારો છો તે મશીન બનાવતું નથી. ફિંગરપ્રિન્ટને જોડાણથી સ્વતંત્ર રીતે વિશ્વાસપાત્ર સ્રોત સામે તપાસો.
સર્વરની બાજુએ, ખાતરી કરો કે ખાતું અધિકૃત છે અને તમે ગોઠવેલી પ્રમાણીકરણ પદ્ધતિ એ જ પ્રસ્તાવિત છે. હાજર હોવા છતાં અવગણાયેલી કી સામાન્ય રીતે નેટવર્કની નહીં પણ પરવાનગી અથવા ગોઠવણીની સમસ્યા છે.
સેવા પ્રવેશને જરૂરી ઓળખ સુધી મર્યાદિત કરો અને નેટવર્ક ફેરફારો માટે અધિકૃત પુનઃપ્રાપ્તિ માર્ગ રાખો.