EC2 તમારા AWS Client VPN લેપટોપ સુધી કેમ પહોંચી શકતું નથી
Client VPN IPv4 ક્લાયન્ટ સ્રોતોને endpoint ના ઇન્ટરફેસમાં અનુવાદિત કરે છે. એટલે જ જવાબ કામ કરે છે અને EC2 તરફથી નવું કનેક્શન નહીં.
AWS Client VPN દ્વારા જોડાયેલું લેપટોપ કોઈ તકલીફ વિના EC2 એપ્લિકેશન સુધી પહોંચે છે. પછી તમે ઊલટું પ્રયત્ન કરો છો, EC2 થી ક્લાયન્ટને આપેલા સરનામા સુધી, અને કનેક્શન અટકી જાય છે અથવા નકારવામાં આવે છે. આ અસમમિતિ ભાગ્યે જ ખૂટતા સિક્યોરિટી ગ્રુપ નિયમને કારણે હોય છે. VPC સબનેટ સાથે જોડાયેલા Client VPN endpoint પર AWS IPv4 ક્લાયન્ટ સ્રોતોને endpoint ના નેટવર્ક ઇન્ટરફેસમાં અનુવાદિત કરે છે, તેથી તમારા લેપટોપનું પ્રતિનિધિત્વ કરતું કોઈ ઇનબાઉન્ડ VPC સરનામું હોતું નથી.
કેપ્ચર શું દર્શાવે છે તેનાથી શરૂ કરો
ક્લાયન્ટ જોડાય છે ત્યારે EC2 હોસ્ટ પર કેપ્ચર લો અને એપ્લિકેશન ખરેખર જે સ્રોત સરનામું જુએ છે તે વાંચો. જો તે ક્લાયન્ટ પૂલનું સરનામું નહીં પણ VPC બાજુનું endpoint ઇન્ટરફેસ હોય, તો એક પણ નિયમ બદલતા પહેલાં અનુવાદની પુષ્ટિ થઈ જાય છે.
ક્લાયન્ટ પૂલ એ ફાળવણીની શ્રેણી છે, રિટર્ન રૂટ સાથેનું સબનેટ નહીં. આ ભેદમાં જ આવી મોટાભાગની તપાસ ખોટી દિશામાં જાય છે.
અસમમિતિ સમજાવતું અનુવાદ
ત્રણ પ્રવાહ એકબીજા સાથે ભળી જાય છે, અને તેમાંથી ફક્ત એક જ એ છે જે લોકો પરીક્ષણ કરે છે.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN ઘટકોનું વર્ણન સ્પષ્ટ કહે છે કે IPv4 ક્લાયન્ટ સ્રોતો endpoint ઇન્ટરફેસમાં અનુવાદિત થાય છે, જે જોવા માટે પૂરતું છે કે મધ્યમ પંક્તિ પાસે સરખાવવા માટે કંઈ કેમ નથી.
નવા કનેક્શનને રૂટ, સરનામા ઉકેલવાનું પગલું અને અધિકૃતિ નિર્ણયની જરૂર પડે છે. બીજા કોઈની સેશનમાંથી અનુવાદની સ્થિતિ આ ત્રણમાંથી એક પણ આપતી નથી.
જવાબ નવું કનેક્શન કેમ નથી
TCP જવાબ હાલની એન્ટ્રી સાથે મેળવવામાં આવે છે, એટલે કોઈ ઇનબાઉન્ડ નિયમ વિના પણ પરત માર્ગ કામ કરે છે. EC2 હોસ્ટ તરફથી નવો SYN મેળવવા માટે કોઈ એન્ટ્રી ધરાવતો નથી, તેથી તે એવા ગંતવ્ય તરફ સામાન્ય આઉટબાઉન્ડ પ્રયાસ બની જાય છે જ્યાં VPC ને પહોંચવાની રીત ખબર નથી.
એટલે જ આને ફક્ત એક દિશામાં જતા ટ્રાફિક તરીકે વર્ણવવું ભ્રામક છે. આ સેશનોમાં પરત ટ્રાફિક સતત વહે છે. માર્ગ વગરનો ભાગ શરૂઆત છે.
કામ કરવું જોઈએ તેવી સેશનને હજી શું તોડે છે
સિક્યોરિટી ગ્રુપ, નેટવર્ક ACL અને લેપટોપનો પોતાનો ફાયરવોલ — જે કનેક્શન સફળ થવા જોઈએ તે બધા માટે મહત્ત્વના છે. નિષ્ફળ ping સૌથી ઓછું કહે છે, કારણ કે ICMP નીતિ ઘણી વાર તમને લગતી TCP નીતિથી અલગ હોય છે.
આ નિયમો અનુવાદિત સ્રોત પ્રમાણે લખો, ક્લાયન્ટ સરનામા પ્રમાણે નહીં. નેટવર્ક પર કદી ન દેખાતા સરનામા સાથે બંધાયેલા નિયમો આ ડિઝાઇનમાં સૌથી સામાન્ય સ્વ-નિર્મિત ભૂલ છે.
જ્યારે VPC એ ખરેખર વાતચીત શરૂ કરવી પડે
જો સેવાએ વર્કસ્ટેશનને જાણ કરવી પડે, તો દિશા ઉલટાવો અને ક્લાયન્ટને એવી કાયમી આઉટબાઉન્ડ ચેનલ રાખવા દો જેના પર સેવા જવાબ આપે. જો આખું દૂરસ્થ નેટવર્ક VPC થી પહોંચી શકાય તેવું હોવું જોઈએ, તો Client VPN પહેલેથી જ એ કરે છે એમ ધારવાને બદલે એવી આર્કિટેક્ચર પસંદ કરો જે તેના પ્રીફિક્સ અને એક્સેસ નીતિ પ્રકાશિત કરે. ક્લાયન્ટ-થી-ક્લાયન્ટ એક્સેસ ત્રીજો, વધુ સાંકડો કેસ છે, જેની પાસે પોતાના રૂટ અને અધિકૃતિ ઑબ્જેક્ટ છે. આમાંથી કંઈ પણ હાલના endpoint પર ફક્ત ચેકબોક્સ નથી.
IPv4 ની સમજૂતીનો વ્યાપ પણ પ્રામાણિક રાખો. હાલનું AWS દસ્તાવેજીકરણ IPv6 ને અલગ કરે છે, જ્યાં એ અનુવાદ લાગુ પડતો નથી, અને અન્ય જોડાણ મોડલ પણ જે અલગ રીતે રૂટ કરે છે.
ત્રણ લેબલવાળા પગલામાં પરીક્ષણ કરો: ક્લાયન્ટ મંજૂર સેશન ખોલે છે, VPC સેવા તે સેશનને જવાબ આપે છે, અને VPC હોસ્ટ ક્લાયન્ટ તરફ નવું સેશન ખોલે છે. પહેલા બે સફળ થાય અને ત્રીજું નિષ્ફળ જાય એ આ ડિઝાઇનનું અપેક્ષિત સ્વરૂપ છે, ફાયરવોલ નિયમોથી પીછો કરવા જેવો ખામી નથી.