SSH બેસ્ટિયન કે સીધી VPN ઍક્સેસ: કઈ નીતિ લાગુ પડે છે?

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

બેસ્ટિયન ખરેખર શું નિયંત્રિત કરે છે તે તપાસો

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

બેસ્ટિયન જે નિયંત્રણ આપે છે તેને નામ આપતા એક વાક્યમાં તારણ જણાવો: લક્ષ્ય-સ્થળ મર્યાદા, બીજું પ્રમાણીકરણ પગલું, સત્ર રેકોર્ડિંગ, અથવા ઘટનાના સમયે કાર્યાત્મક દૃશ્યતા. એ જ વાક્યને બદલીનીતિએ જાળવવાનું છે.

લક્ષ્ય માર્ગોને અલગ પારખી શકે છે કે નહીં તે તપાસો

સ્રોત-સરનામાના નિયમો ત્યાં સુધી જ કામ કરે છે જ્યાં સુધી બંને માર્ગ જુદા જુદા સ્રોત સરનામાં સાથે આવે. સર્વર સબનેટ તરફનો ટ્રાફિક માસ્ક કરતું VPN ગેટવે એ ફરક ભૂંસી નાખે છે, અને પછી પોર્ટ 22 પરનું દરેક જોડાણ ગેટવેથી આવતું લાગે છે. તપાસ લક્ષ્ય પર જ સ્થાનિક છે અને એક ક્ષણ લે છે: સ્થાપિત SSH સત્રોની યાદી બનાવો અને દરેક માટે પીઅર સરનામું વાંચો.

જ્યારે બંને માર્ગ એક જ સરનામામાં ભેગા થાય, ત્યારે ભેદ પહેલાં કરવો પડે: VPNને કયા લક્ષ્યસ્થળો મોકલવાની મંજૂરી છે અને ગેટવેના પોતાના ફિલ્ટર દ્વારા. એ સ્થિતિમાં લક્ષ્ય પર નિયમ ઉમેરવાથી જે આવે છે તે બદલ્યા વિના સીમાનો ભ્રમ ઊભો થાય છે.

દરેક રેકોર્ડ ખરેખર શું રાખે છે તે તપાસો

ત્રણ જુદા લૉગ ત્રણ જુદી ઘટનાઓનું વર્ણન કરે છે, અને એક પણ બીજાનું સ્થાન લેતું નથી. VPNનો જોડાણ-રેકોર્ડ દર્શાવે છે કે એક ઓળખ નેટવર્ક વ્યાપમાં દાખલ થઈ. બેસ્ટિયનનો ફોરવર્ડિંગ રેકોર્ડ દર્શાવે છે કે TCP ચેનલ તેને લક્ષ્યસ્થળ અને પોર્ટ તરફ છોડે છે. લક્ષ્યનો પ્રમાણીકરણ લૉગ દર્શાવે છે કે ખાતાએ SSH દ્વારા સાઇન ઇન કર્યું. તેમને સાથે વાંચવાથી સમયરેખા બને છે; એકલું વાંચવાથી અનુમાન બને છે.

એ રેકોર્ડમાંથી કોઈ પણ ક્લાઇન્ટ અને લક્ષ્ય વચ્ચેના એન્ક્રિપ્ટેડ સત્રની અંદર શું થયું તે ધરાવતું નથી. જો આદેશ-સ્તરની સમીક્ષા જરૂરી હોય, તો તેને પોતાના ડેટા-હેન્ડલિંગ નિયમો સાથે જાણી જોઈને તૈનાત કરેલી રેકોર્ડિંગ વ્યવસ્થા જોઈએ. જમ્પ-હોસ્ટ લૉગમાંથી એની અપેક્ષા રાખવી એ જ રીત છે જેમાં ઓડિટ અંતર મહત્ત્વનું ન થાય ત્યાં સુધી છુપાયેલું રહે છે.

નીતિ ખરેખર ક્યાં લાગુ થાય છે તે તપાસો

ProxyJump જેવી ક્લાઇન્ટ સેટિંગ વિનંતી છે, પ્રતિબંધ નહીં. લક્ષ્યસ્થળ પહોંચવા યોગ્ય હોય ત્યારે OpenSSH આનંદથી સીધું જોડાણ ખોલશે, તેથી લૅપટૉપના ગોઠવણી ફાઇલો ઇરાદો વર્ણવે છે જ્યારે ફાયરવૉલ પરિણામ નક્કી કરે છે. અમલ VPN ગેટવેના મંજૂર લક્ષ્યસ્થળો અને લક્ષ્યના પોતાના ઍક્સેસ નિયમોમાં આવે છે, અને વપરાશકર્તા બંનેમાંથી એક પણ સંપાદિત કરી શકતો નથી. તે જ સમયે વૈકલ્પિક માર્ગોનું ઓડિટ કરો: બીજું ઇન્ટરફેસ, જાહેર શ્રોતા, મેશ સ્તર અથવા જૂની સાઇટ-થી-સાઇટ ટનલ — દરેક તમે હમણાં બંધ કરેલો શૉર્ટકટ પુનઃસ્થાપિત કરી શકે છે.

તો પણ ProxyJump ગોઠવો, કારણ કે તે મંજૂર માર્ગને સહેલો બનાવે છે અને નિયમિત કામને અપવાદ બનાવતું અટકાવે છે. વિશ્વાસ કરતા પહેલાં ક્લાઇન્ટ ખરેખર શું ઉકેલે છે તેની પુષ્ટિ કરો.

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

જાણી જોઈને કરેલા સીધા પ્રયાસથી ચકાસો

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

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

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