SSH ફોરવર્ડિંગ, VPN કે RD Gateway: એક RDP ડેસ્કટોપ માટે કયો રસ્તો?

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

પ્રશ્ન પ્રોટોકોલ નહીં, વ્યાપ છે

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

પ્રવેશ ઓળખને ડેસ્કટોપ પર સાઇન ઇન કરતા Windows ખાતાથી અલગ રાખો. નીચેની દરેક રચનામાં બંને છે, અને તેમને ભેગા કરવાથી જ જમ્પ હોસ્ટ ખાતાને કોઈએ ધાર્યું હોય તેનાથી વધુ સત્તા મળે છે.

એક ફોરવર્ડ કરેલી TCP સેવા

મંજૂર SSH જમ્પ હોસ્ટ સ્થાનિક શ્રોતાને તે પહોંચી શકે તેવી RDP સેવા તરફ ફોરવર્ડ કરી શકે છે. જ્યારે તે ફક્ત વપરાશકર્તાના પોતાના મશીન માટે હોય ત્યારે તે શ્રોતાને loopback સાથે બાંધો, જે સ્થાનિક ફોરવર્ડનો સામાન્ય હેતુ છે. ફોરવર્ડ એક વ્યક્તિ માટે સુવિધા છે, ટીમ માટે સેવા નહીં.

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

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

એક રાઉટેડ ખાનગી વર્કસ્પેસ

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

માર્ગો અને સંસાધન પરવાનગીઓને ઇચ્છિત ગંતવ્યો સુધી મર્યાદિત કરો. જોડાયેલ વપરાશકર્તા આપોઆપ આખું LAN લાયક નથી, અને ગંતવ્યની ફાયરવોલ વત્તા Windows સાઇન-ઇન અધિકારો VPN બદલી ન શકે તેવી અલગ સીમાઓ રહે છે.

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

RDP-વિશિષ્ટ ગેટવે

Remote Desktop Gateway નેટવર્ક સીમાને બદલે RDP-વિશિષ્ટ સીમા આપે છે. તેની કનેક્શન અધિકૃતિ નીતિ નક્કી કરે છે કે કોણ જોડાઈ શકે, અને તેની સંસાધન અધિકૃતિ નીતિ નક્કી કરે છે કે તેના દ્વારા કયા આંતરિક સંસાધનો સુધી પહોંચી શકે. બંને નીતિઓ ઉત્પાદનનો ભાગ છે, વૈકલ્પિક વધારા નહીં.

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

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

ત્રણેયને હજી શું જોઈએ

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

નીતિ જ્યાં માંગે ત્યાં પ્રવેશ બિંદુ પર MFA લાગુ કરો, અને ગંતવ્યના ખાતા નિયંત્રણો રાખો. બંને પૂરક છે: પહેલું નક્કી કરે છે કે કોણ દરવાજા સુધી પહોંચી શકે, બીજું નક્કી કરે છે કે કોણ તેને ખોલી શકે. કોઈપણ એક છોડવાથી એવી રચના રહે છે જે પૂર્ણ દેખાય છે અને નથી.

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