AWS Client VPN કનેક્ટ થયું, પણ EC2 હજી જવાબ આપતું નથી

મારું લેપટોપ કનેક્ટ થયેલું દેખાડતું હતું. AWS Client VPN ક્લાયન્ટ તેની લીલી સ્થિતિ બતાવતો હતો, endpoint એ સેશન નોંધ્યું, અને તો પણ હું ખાનગી સબનેટમાં EC2 ઇન્સ્ટન્સ પર MongoDB પોર્ટ ખોલી શક્યો નહીં. દેખીતી રીતે કંઈ તૂટેલું ન હતું: સર્ટિફિકેટ માન્ય હતું, પ્રોફાઇલ કન્સોલમાંથી આવ્યું હતું, અને ટનલ ટ્રાફિક વહન કરતી હતી. ભૂલ મારી હતી, કારણ કે હું કનેક્ટ થયુંને ઑથરાઇઝ્ડ તરીકે વાંચતો હતો.

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

નીચેની તપાસો એ ક્રમ છે જે હું હવે વાપરું છું.

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

હેન્ડશેક દરમિયાન endpoint ક્લાયન્ટ સર્ટિફિકેટને તેના trust store સામે ચકાસે છે, અથવા જ્યારે SAML ગોઠવાયેલું હોય ત્યારે બ્રાઉઝરને તમારા identity provider પર મોકલે છે. જો તે પસાર થાય, તો ક્લાયન્ટને endpoint ના ક્લાયન્ટ CIDR માંથી સરનામું મળે છે અને કન્સોલ સક્રિય કનેક્શન બતાવે છે. તે આદાનપ્રદાનમાં ક્યારેય પણ પૂછાતું નથી કે તમે 10.0.4.17 સુધી પોર્ટ 27017 પર પહોંચી શકો છો કે નહીં.

ગંતવ્ય માટેની પરવાનગી endpoint પર અલગ ઑબ્જેક્ટ છે. દરેક ફ્લો ઑથરાઇઝેશન નિયમો સામે મેળવવામાં આવે છે, અને દરેક નિયમ ગંતવ્ય CIDR ને જે ગ્રુપને નિયમ આપવામાં આવ્યો છે તેની સાથે જોડે છે. જ્યારે કોઈ નિયમ ગંતવ્યને આવરી લેતો નથી, endpoint સેશન સ્વીકારે છે અને ટ્રાફિક કાઢી નાખે છે. કોઈ બેનર નથી, પુનઃકનેક્શન લૂપ નથી, અને ક્લાયન્ટ UI માં નકાર્યું એમ કહેતું કંઈ નથી.

ઑથરાઇઝેશન નિયમની સરખામણી VPC સાથે નહીં, સ્રોત સાથે કરો

નિયમોની યાદી બનાવો અને તેમને ઇન્સ્ટન્સ પાસે ખરેખર જે સરનામું છે તેની બાજુમાં રાખો:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

આઉટપુટ દરેક નિયમ માટે ગંતવ્ય CIDR અને ગ્રુપ ID બતાવે છે. તેમાં બે નિષ્ફળતાઓ છુપાયેલી છે. નિયમ 10.0.0.0/16 ને ઑથરાઇઝ કરી શકે છે જ્યારે ઇન્સ્ટન્સ 10.1.0.0/16 પર પીઅર કરેલ VPC માં બેઠું છે; પીઅરિંગ રૂટ અસ્તિત્વમાં છે, પણ બીજી શ્રેણી માટે કોઈએ ઑથરાઇઝેશન નિયમ લખ્યો નથી. અથવા નિયમ એવા ડિરેક્ટરી ગ્રુપ તરફ ઇશારો કરે છે જેમાં વપરાશકર્તા ડિરેક્ટરીમાં જોડાય છે પણ endpoint જે ગ્રુપનું મૂલ્યાંકન કરે છે તેમાં નહીં.

ગંતવ્યને આવરી લેતો સૌથી સાંકડો નિયમ લખો, અને બીજો નિયમ ત્યારે જ ઉમેરો જ્યારે બીજું CIDR ખરેખર જરૂરી હોય. ઝડપી શરૂઆતમાંથી આવેલો વિશાળ 0.0.0.0/0 નિયમ કામ કરે છે, અને એટલે જ તે પ્રોડક્શન સુધી ટકી રહે છે અને મોડેલ છુપાવે છે.

બે રૂટ ટેબલ નક્કી કરે છે કે પેકેટ આગળ વધશે કે નહીં

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

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

એવો રૂટ શોધો જેનું ગંતવ્ય સ્રોતના CIDR સાથે મેળ ખાય અને જેનું લક્ષ્ય સંકળાયેલું સબનેટ હોય. જો રૂટ ન હોય તો ઉમેરો. જો હોય અને હોસ્ટ હજી ચૂપ હોય, તો અંતર VPC બાજુ છે, એટલે સંકળાયેલા સબનેટના રૂટ ટેબલ સાથે સરખામણી કરો.

ક્લાયન્ટ બાજુનું એક સેટિંગ ટનલ ન તોડતાં રૂટિંગ તોડે છે: route-nopull ધરાવતું પ્રોફાઇલ. આ સૂચના OpenVPN-આધારિત ક્લાયન્ટને સર્વર ધકેલે તે રૂટ્સને અવગણવા કહે છે, એટલે ઇન્ટરફેસ ફક્ત endpoint ના પોતાના સરનામા સાથે ઉપર આવે છે અને ગંતવ્યને સહેલાઈથી કોઈ રૂટ જ નથી. Linux પર ip route show અથવા macOS પર netstat -rn વડે ચકાસો કે tun ઇન્ટરફેસ દ્વારા રૂટ છે કે નહીં. જો ન હોય, તો એક્સપોર્ટ કરેલા પ્રોફાઇલમાંથી route-nopull દૂર કરો અને ફરી કનેક્ટ કરો જેથી ધકેલાયેલા રૂટ્સ લાગુ થાય.

સિક્યોરિટી ગ્રુપ્સ તમારું ક્લાયન્ટ સરનામું જોતા નથી

આ એ ભાગ છે જે મેં આખી બપોર ખોટો રાખ્યો. સબનેટ સાથે સંકળાયેલા IPv4 endpoint માટે, સેવા ક્લાયન્ટના સ્રોત સરનામાને તે સબનેટમાં endpoint ના નેટવર્ક ઇન્ટરફેસના સરનામામાં અનુવાદિત કરે છે. ઇન્સ્ટન્સ સુધી પહોંચતું પેકેટ તમારા ક્લાયન્ટે દેખાડેલું સરનામું ધરાવતું નથી, એટલે ક્લાયન્ટ પૂલ, ધારો કે 172.16.0.0/22, ને મંજૂરી આપતો સિક્યોરિટી ગ્રુપ નિયમ કશાઈ સાથે મેળ ખાતો નથી.

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

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

પ્રથમ નિષ્ફળતા પર અટકતો આઇસોલેશન ક્રમ

આને ક્રમમાં કરો અને જ્યાં એક નિષ્ફળ જાય ત્યાં અટકો. દરેક પગલું બધા સ્તરોને નહીં, એક સ્તરને બાદ કરે છે.

1. સેશને કઈ ઓળખ વાપરી અને endpoint કયા ગ્રુપનું મૂલ્યાંકન કરે છે તેની ખાતરી કરો. એક trust store નું સર્ટિફિકેટ ડિરેક્ટરીમાંથી આવેલા SAML દાવા કરતાં અલગ પ્રિન્સિપાલ છે.
2. ખાતરી કરો કે ઑથરાઇઝેશન નિયમ તે ગ્રુપ માટે સ્રોતના CIDR ને આવરી લે છે.
3. ખાતરી કરો કે endpoint રૂટ અસ્તિત્વમાં છે અને સંકળાયેલા સબનેટને લક્ષ્ય બનાવે છે, પછી ખાતરી કરો કે સબનેટનું રૂટ ટેબલ આગળ મોકલી શકે છે.
4. ખાતરી કરો કે સિક્યોરિટી ગ્રુપ પોર્ટને ક્લાયન્ટ પૂલમાંથી નહીં, endpoint ઇન્ટરફેસમાંથી મંજૂરી આપે છે.
5. એપ્લિકેશન સમસ્યાને ક્લાયન્ટ માર્ગની સમસ્યાથી અલગ પાડવા VPC ની અંદરથી, એ જ સબનેટની બીજી ઇન્સ્ટન્સ પર SSM સેશન વડે કસોટી કરો.

જ્યારે પગલાં નિર્ણાયક ન હોય, ત્યારે હું આ ટેબલ પર આધાર રાખું છું:

ખાતાની બે વિગતો એવા લક્ષણો ઉત્પન્ન કરે છે જે પરવાનગીની નિષ્ફળતા જેવા લાગે. દરેક વપરાશકર્તાને અલગ ક્લાયન્ટ સર્ટિફિકેટની જરૂર છે; એકને બે મશીનોમાં વહેંચવાથી સેશનો એકબીજાને ખસેડે છે, અને પરિણામ નકાર નહીં પણ પુનઃકનેક્શન લૂપ હોય છે. જ્યારે નવું endpoint બને છે, ત્યારે કન્સોલ એવું DNS નામ બતાવે છે જે અમુક ક્લાયન્ટ આવૃત્તિઓ ફક્ત endpoint પૃષ્ઠ પર દેખાતા અવ્યવસ્થિત પ્રીફિક્સ સાથે જ સ્વીકારે છે, એટલે નામ ફરી બનાવવાને બદલે પૂરું નામ કૉપી કરો.

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