AWS Client VPN પર અનિયમિત ઍક્સેસ: દરેક જોડાયેલા સબનેટનું ઓડિટ કરો
કેટલાક AWS Client VPN સત્રો ઍપના VPC સુધી પહોંચે છે જ્યારે અન્ય સમય સમાપ્ત થાય છે. પહેલા દરેક સંબંધના VPC રૂટ ટેબલ સાથે એન્ડપોઇન્ટ રૂટની તુલના કરો.
એક વપરાશકર્તા જોડાય છે, આંતરિક ઍપ ખોલે છે અને જવાબ મેળવે છે; એ જ એન્ડપોઇન્ટ પરનો સહકર્મી એ જ Wi-Fi પરનાં સમાન લેપટોપથી સમય સમાપ્તિ મેળવે છે. આ પેટર્ન એ client VPN એન્ડપોઇન્ટની ઓળખ છે જેમાં એક કરતાં વધુ જોડાયેલા સબનેટ છે, જ્યાં માર્ગો સમાન નથી. હું આ કન્સોલથી બહારની તરફ જઉં છું, કારણ કે બે ટૅબ નક્કી કરે છે કે બાકીની તપાસ કરવા જેવી છે કે નહીં. ક્લાયન્ટ રૂપરેખાંકનમાં કંઈ પણ આ સમજાવતું નથી.
એન્ડપોઇન્ટથી શરૂ કરો અને સંબંધોની સૂચિ બનાવો
VPC કન્સોલમાં Client VPN endpoints ખોલો, એન્ડપોઇન્ટ પસંદ કરો અને Associations ટૅબ વાંચો. દરેક સંબંધ એ ઉપલબ્ધતા ઝોનમાંનું સબનેટ છે, અને કનેક્શન બને ત્યારે સેવા જે પસંદ કરે તેના પર ક્લાયન્ટ ઉતરે છે. સબનેટ ID અને દરેક ખરેખર વાપરે છે તે રૂટ ટેબલ નોંધો, કારણ કે એ બે યાદી જ તમે કરવા જઈ રહ્યા છો તે તુલના છે.
જો એન્ડપોઇન્ટ ફક્ત એક સંબંધ બતાવે, તો આ સિદ્ધાંત ખોટો છે અને ક્લાયન્ટ વધુ સારો શંકાસ્પદ છે.
એન્ડપોઇન્ટ રૂટ ટેબલની દરેક સંબંધ સાથે તુલના કરો
એ જ એન્ડપોઇન્ટ પર Route table ટૅબ ખોલો. ત્યાંના દરેક ગંતવ્ય CIDRનું એક લક્ષ્ય છે, અને client VPNમાં લક્ષ્ય ગેટવે નહીં પણ સંબંધ છે. AWS દરેક જોડાયેલા સબનેટ માટે ગંતવ્ય એન્ટ્રી માગે છે, તેથી ફક્ત એકને લક્ષ્ય બનાવતો રૂટ ઍક્સેસને સત્ર ક્યાં ઉતર્યું તેના પર નિર્ભર બનાવે છે. તમને ખરેખર જરૂરી ગંતવ્ય તપાસો, પછી તેનો અધિકૃતિ નિયમ તપાસો, કારણ કે રૂટ માર્ગ આપે છે અને નિયમ નક્કી કરે છે કે કોણ તેનો ઉપયોગ કરી શકે.
બંને સ્તરોને ટેબલમાં ગોઠવો એટલે ખામી ચૂકી જવી મુશ્કેલ છે.
| Associated subnet | Endpoint route to 10.200.0.0/16 | VPC route in that subnet |
|---|---|---|
| subnet-aaa | Targets the association | 10.200.0.0/16 to pcx-example |
| subnet-bbb | Targets the association | No matching entry |
બીજી પંક્તિ મોટાભાગની ટિકિટમાં આખો બગ છે. એન્ડપોઇન્ટ રૂટ હાજર છે, તેથી કોઈ આગળ જોતું નથી, અને પેકેટ એક હોપ પછી VPCની અંદર મૃત્યુ પામે છે.
દરેક સબનેટને તેના અસરકારક રૂટ ટેબલ સુધી અનુસરો
જે સબનેટનું સ્પષ્ટ રૂટ ટેબલ સંબંધ નથી તે VPCનું મુખ્ય ટેબલ વારસામાં લે છે. જે ટેબલ ખરેખર અમલમાં છે તે વાંચો, જેનું નામ યોગ્ય લાગે તે નહીં, અને પંક્તિના લેબલને બદલે ગંતવ્ય અને લક્ષ્યની તુલના કરો.
AWSની અનિયમિત ઍક્સેસ માર્ગદર્શિકા આને સંબંધો આખા રૂટ કવરેજ તરીકે રજૂ કરે છે, જે યોગ્ય મોડેલ છે. એન્ડપોઇન્ટ પેકેટને સબનેટ સુધી પહોંચાડે છે, અને તે સબનેટના ટેબલને હજી પણ ખબર હોવી જોઈએ કે ઍપ્લિકેશન નેટવર્ક ક્યાં રહે છે.
જે ટેબલ તેનું માલિક છે તેમાં ખૂટતી પંક્તિ સુધારો. કાર્યરત સબનેટમાંથી આખું રૂટ ટેબલ કૉપિ કરવાથી ઇન્ટરનેટ, ઉપકરણ અને અલગીકરણની પસંદગીઓ પણ કૉપિ થાય છે જે ક્યારેય આ માટે ધ્યાનમાં નહોતી, અને એ વિનિમય સામાન્ય રીતે તમે શરૂ કરેલા વિક્ષેપ કરતાં ખરાબ હોય છે.
અધિકૃતિ નિયમો તપાસો, પછી પાછળનો માર્ગ
અધિકૃતિ નિયમો ગંતવ્ય અને જૂથ પ્રમાણે હોય છે અને રૂટથી અલગ મૂલ્યાંકન પામે છે. જે ગંતવ્યમાં દરેક જગ્યાએ રૂટ છે પણ વપરાશકર્તાના જૂથ માટે નિયમ નથી તે સ્વસ્થ દેખાતા રૂટ ટેબલ સાથે કાળા છિદ્ર જેવું વર્તે છે.
પાછળનો માર્ગ પણ એટલું જ ધ્યાન માગે છે. peering કનેક્શનને ઍપ્લિકેશન VPCમાં ક્લાયન્ટ CIDR તરફ પાછા જતો રૂટ, બંને છેડે ટ્રાફિકની મંજૂરી આપતા સિક્યોરિટી જૂથ નિયમો અને તેને ફેંકી ન દેતા નેટવર્ક ACLની જરૂર છે. એકતરફી પહોંચ, જ્યાં ping કામ કરે છે અને TCP હેન્ડશેક નહીં, સામાન્ય રીતે VPN નહીં પણ ACL અથવા સિક્યોરિટી જૂથ તરફ ઇશારો કરે છે.
એન્ડપોઇન્ટના પોતાના સિક્યોરિટી જૂથો સંબંધના ઇલાસ્ટિક નેટવર્ક ઇન્ટરફેસ પર બેસે છે, તેથી ક્લાયન્ટ CIDRથી ઍપ્લિકેશન પોર્ટની મંજૂરી આપતો નિયમ ફક્ત ઇન્સ્ટન્સ સાથે નહીં, સંબંધ સાથે જોડવો પડે.
એક નસીબદાર વિનંતીથી નહીં, ફરી જોડાઈને ચકાસો
split tunnel સાથે, કનેક્શન સ્થપાય ત્યારે એન્ડપોઇન્ટ રૂટ મોકલાય છે, તેથી બદલાયેલ રૂટ સમૂહ જોડાયેલા રહેતા ક્લાયન્ટ સુધી ક્યારેય પહોંચતો નથી. સમર્થિત ક્લાયન્ટ દ્વારા ડિસ્કનેક્ટ કરી ફરી જોડાઓ, પછી મશીન પર નવા રૂટ હાજર છે તેની ખાતરી કરો.
અંતે, ક્લાયન્ટને મળેલા સરનામા સાથે કનેક્શન લોગનું સહસંબંધ કરો, અને એક કરતાં વધુ સંબંધ સુધી પહોંચવા પૂરતી વખત ચકાસણીનું પુનરાવર્તન કરો. સુધારા પછીની એક સફળ વિનંતી સાબિત કરે છે કે એક માર્ગ કામ કરે છે, અને ટિકિટ બીજા વિશે હતી.