AWS Client VPN કે Site-to-Site: કોણ કનેક્શન ખોલે છે તે તપાસો
Client VPN ઉપકરણ કે વપરાશકર્તાને પ્રમાણિત કરે છે; Site-to-Site ગેટવેને AWS સાથે જોડે છે. ચાર તપાસ નક્કી કરે છે કે તમારા લેપટોપ કે શાખાને ખરેખર કઈ જોઈએ.
ચાર તપાસ આ નક્કી કરે છે, અને તેમાંથી એક પણ પ્રોટોકોલનું નામ નથી. કોણ કનેક્શન ખોલે છે, AWS શું પ્રમાણિત કરે છે, કનેક્શન તમારા નેટવર્ક સાથે કેવી રીતે જોડાય છે, અને તેની સાથે કઈ રાઉટિંગ અને નીતિ આવે છે. આનો ક્રમમાં જવાબ આપો અને ઉત્પાદનની પસંદગી સામાન્ય રીતે જાતે થઈ જાય છે; ડિઝાઇન ખરીદ્યા પછી જવાબ આપો તો તમે એવી ટનલનો બચાવ કરશો જે સમસ્યાનો ખોટો અડધો ભાગ ઉકેલે છે. ચારમાંથી એક પણ તમને સાઇફર પસંદ કરવાનું કહેતું નથી, તેથી પ્રોટોકોલ-પ્રથમ ડિઝાઇન સામાન્ય રીતે એ સંકેત છે કે જરૂરિયાતો ક્યારેય લખાઈ નહોતી.
દરેક તપાસ તમે વાપરવાનું વિચારી રહ્યા છો તે વાસ્તવિક એન્ડપોઇન્ટ, ક્લાયન્ટ અને સરનામા-કુટુંબ સામે કરો, શ્રેણી સામે નહીં. મેનેજ્ડ VPN ઉત્પાદનો તેઓ જેવા દેખાય છે તે OpenVPN અને IPsec બિલ્ડિંગ બ્લોક્સથી અલગ છે.
પ્રથમ, કોણ કનેક્શન ખોલે છે
જો જેને ઍક્સેસની જરૂર છે તે લેપટોપ, ફોન કે એક જ એડમિનિસ્ટ્રેટરનું વર્કસ્ટેશન હોય, તો કનેક્શન દૂરના ઉપકરણથી શરૂ થાય છે અને ડિઝાઇન દૂરસ્થ-ક્લાયન્ટ ઍક્સેસ છે. જો જેને ઍક્સેસની જરૂર છે તે એક રાઉટર પાછળની મશીનોથી ભરેલી શાખા હોય, તો કનેક્શન તે રાઉટરથી શરૂ થાય છે અને ડિઝાઇન ગેટવે-થી-ગેટવે છે. આ એ તપાસ છે જે મોટાભાગના કિસ્સા નક્કી કરે છે, અને વેચાણકર્તાની રજૂઆતે વાતચીતને પહેલેથી સાઇફરની આસપાસ ફ્રેમ કરી હોય ત્યારે લોકો જે છોડી દે છે તે પણ આ જ છે.
જો તમે શરૂ કરનાર ઘટકનું નામ ન કહી શકો તો અહીં થોભો. એક ટનલથી બંને કિસ્સા સંભાળવાનો પ્રયાસ કરતી ડિઝાઇન સામાન્ય રીતે પોતાને ગેટવે હોવાનું દર્શાવતા ક્લાયન્ટ સેશન પર પૂરી થાય છે.
બીજું, AWS શું પ્રમાણિત કરે છે
Client VPN સાથે AWS રૂપરેખાંકિત ક્લાયન્ટ કે વપરાશકર્તા ઓળખ પ્રમાણિત કરે છે: પ્રમાણપત્રો, ડિરેક્ટરી કે ફેડરેટેડ ઓળખ, સેટઅપ પ્રમાણે. Site-to-Site VPN સાથે AWS ગેટવે પીઅરની ઓળખ પ્રમાણિત કરે છે. એ ફરક સપાટીનો નથી. એક મોડેલ વપરાશકર્તાઓ ઉમેરીને અને તેમના ઓળખપત્રો રદ કરીને સ્કેલ થાય છે; બીજું એક ગેટવે પાછળ જે હોય તે બધા પર ભરોસો કરીને સ્કેલ થાય છે.
ગેટવે પ્રમાણીકરણ તેની પાછળના દરેક કર્મચારી કે એપ્લિકેશનને પ્રમાણિત કરતું નથી, તેથી ટનલ પોતે ભરોસાપાત્ર હોય ત્યારે પણ એપ્લિકેશન ઓળખ અને સંસાધન-સ્તરીય ઍક્સેસ ચાલુ રાખો. જેનું રાઉટર માન્ય પીઅર ઓળખ ધરાવે છે તે શાખાને આપોઆપ એમ વાંચવું જોઈએ નહીં કે એ મકાનનું દરેક ડેસ્ક અધિકૃત છે.
ત્રીજું, કનેક્શન કેવી રીતે જોડાય છે
Client VPN VPC સબનેટ સંલગ્નતાઓ કે સમર્થિત સીધા Transit Gateway જોડાણ દ્વારા જોડાય છે. Site-to-Site VPN AWS VPN લક્ષ્ય સાથે જોડાય છે, સામાન્ય રીતે વર્ચ્યુઅલ ખાનગી ગેટવે કે Transit Gateway. Client VPN આર્કિટેક્ચર માર્ગદર્શિકા Transit Gateway વિકલ્પનું દસ્તાવેજીકરણ કરે છે, અને તેનું અસ્તિત્વ લેપટોપ સેશનને શાખા ગેટવેમાં ફેરવતું નથી કે ઉપર વર્ણવેલ ક્લાયન્ટ પ્રમાણીકરણ અને અધિકૃતિ દૂર કરતું નથી.
રૂટ ડિઝાઇન કરતા પહેલાં તમારું ખાતું અને પ્રદેશ ખરેખર કયું જોડાણ સમર્થન કરે છે તે તપાસો, પછી તપાસો કે એ જોડાણ કોનું છે. દસ્તાવેજમાં હોય પણ એવા નેટવર્ક પર હોય જેને તમે રૂપરેખાંકિત કરી શકતા નથી, તો એ વિકલ્પ નથી.
ચોથું, તેની સાથે કઈ રાઉટિંગ અને નીતિ આવે છે
Client VPN તમે મંજૂર કરો તે લક્ષ્ય નેટવર્ક માટે ક્લાયન્ટ કનેક્શન વ્યવસ્થાપન અને અધિકૃતિ નિયમો લાવે છે. જોડાયેલા વપરાશકર્તાને હજી પણ ઇચ્છિત એન્ડપોઇન્ટ રૂટ, તેને મંજૂર કરતો અધિકૃતિ નિયમ, અને સંસાધન પોતે જે ઍક્સેસ માગે તે જોઈએ છે. Site-to-Site VPN ગ્રાહક ગેટવે દ્વારા રજૂ થતા નેટવર્ક વચ્ચે રૂટ કરે છે, ડિઝાઇન પ્રમાણે સમર્થિત સ્થિર રૂટ કે BGP વાપરીને, તેથી શાખા રાઉટર પાછળની વ્યક્તિગત મશીનોને દરેકને ક્લાયન્ટ લોગિનની જરૂર પડતી નથી.
કોઈ પણ દિશામાં શ્રેણીમાંથી અસમર્થિત વર્તન અનુમાન કરશો નહીં. દૂરસ્થ-ઍક્સેસ VPN સાર્વત્રિક રીતે પરત ટ્રાફિક વહન કરવા કે ગેટવે ગોઠવણોને સમર્થન આપવામાં અસમર્થ નથી, અને IPsec NAT દ્વારા આપોઆપ અવરોધાતું નથી — AWS NAT ટ્રાવર્સલ અને ગ્રાહક-ગેટવે જરૂરિયાતોનું દસ્તાવેજીકરણ કરે છે, અને સમર્થિત ગેટવે રૂપરેખાંકન એ જ સાચી મર્યાદા છે. ક્લાયન્ટ તરફ શરૂ થતા કનેક્શનની માગ કરતા પહેલાં કે એક સેશન પાછળ LAN ફોરવર્ડ કરતા પહેલાં તમારા એન્ડપોઇન્ટની મર્યાદાઓ તપાસો. એ જ સાવધાની સરનામા-કુટુંબોને પણ લાગુ પડે છે: IPv4 પર કામ કરતું એન્ડપોઇન્ટ IPv6 માર્ગ સૂચવતું નથી, તેથી તમારો ક્લાયન્ટ કે ગેટવે ખરેખર જે કુટુંબ પર વાટાઘાટ કરશે તેની પુષ્ટિ કરો.
Site-to-Site VPN તમને પ્રતિ કનેક્શન બે ટનલ આપે છે, અને એ રીડન્ડન્સી ધારી શકાય તેવી સુવિધા નહીં પણ ડિઝાઇન કાર્ય છે. ગ્રાહક-ગેટવેનું સંચાલન, રૂટ ફેઇલઓવર અને પરીક્ષણ કવરેજ બધું જ યોજવું પડે; એક લેપટોપ સેશનને અમૂર્ત VPN સર્વર સાથે સરખાવવાથી બંનેમાંથી કોઈના વિશે કંઈ સાબિત થતું નથી.
જ્યાં બે ડિઝાઇન મળે છે
સેવાઓ પરસ્પર-વિશિષ્ટ નથી, અને સામાન્ય ઉત્પાદન આકાર બંને વાપરે છે: કર્મચારીઓ Client VPN પર, શાખા નેટવર્ક Site-to-Site પર, જે લક્ષ્યોએ વાત કરવી છે તેમની વચ્ચે સ્પષ્ટ રૂટ અને ઍક્સેસ નીતિ સાથે. કોષ્ટક ચાર તપાસનો સારાંશ છે, તેમને કરવાનો વિકલ્પ નહીં.
| Question | AWS Client VPN | AWS Site-to-Site VPN |
|---|---|---|
| Who establishes it? | A client on a remote device | A customer gateway device or appliance |
| What is authenticated? | The client or user identity | The gateway peer identity |
| How does it attach? | VPC subnet association or Transit Gateway | Virtual private gateway or Transit Gateway |
| What carries the path? | An OpenVPN-based client tunnel | IPsec tunnels to AWS endpoints |
એક વસ્તુ જે બંનેમાંથી કોઈ ઉત્પાદન બદલતું નથી: એવી એપ્લિકેશન માટે TLS જેની એન્ક્રિપ્શન જરૂરિયાત VPN એન્ડપોઇન્ટથી આગળ જાય છે. જો તમારું અનુપાલન ક્ષેત્ર એપ્લિકેશન પર પૂરું થાય, તો ટનલ પરિવહન છે અને પ્રમાણપત્ર હજી પણ નિયંત્રણ છે.
ડિઝાઇન સમીક્ષા પહેલાં ચાર જવાબ લખો, દરેક એક લાઇનમાં. જ્યારે તેમાંથી બે વિરોધાભાસી હોય — કહો, વપરાશકર્તા-પ્રમાણિત ક્લાયન્ટ ડિઝાઇન સાથે શાખા-માપની રાઉટિંગ જરૂરિયાત — તો એ વિરોધાભાસ જ શોધ છે, અને કટઓવર દરમિયાન કરતાં અત્યારે જોવું સસ્તું છે.