AWS Client VPN: લોગિન સફળ, પણ સબનેટ સુધી પહોંચી શકાતું નથી

તમારો ક્લાયન્ટ Connected કહે છે, સર્ટિફિકેટ માન્ય છે, અને ઇન્ટ્રાનેટ પૃષ્ઠ હજી સમય સમાપ્ત થવા પર અટકે છે. આ તફાવત ભાગ્યે જ પ્રમાણીકરણ હોય છે. AWS Client VPN લોગિનથી અલગ ગંતવ્યોને અધિકૃત કરે છે, અને સામાન્ય રીતે બે કારણો હોય છે: ઓળખ પ્રદાતાએ મોકલેલા સાથે ન મળતી જૂથ કિંમત, અને પહોળા નિયમને હરાવતો વધુ ચોક્કસ ગંતવ્ય નિયમ. ક્યાં જોવું તે ખબર હોય તો બંને endpoint રૂપરેખાંકનમાં દેખાય છે.

લોગિન સફળ થયું; નિયમ મેળ ખાધો નહીં

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

endpoint પાસે એવો અધિકૃતિ નિયમ છે કે જેનું ગંતવ્ય નિષ્ફળ જતું સરનામું ધરાવે છે તેની ખાતરી કરીને શરૂ કરો. જો મેળ ખાતો નિયમ ન હોય, તો જોડાણ યોગ્ય રીતે વર્તે છે; નીતિ ખૂટે છે.

જૂથની કિંમત ખરેખર ક્યાંથી આવે છે

Active Directory સાથે, access-group ફીલ્ડ જૂથનું પ્રદર્શન નામ નહીં, જૂથનું SID ધરાવે છે. SAML ફેડરેશન સાથે, તે જૂથ ID અથવા નામ ધરાવે છે જે ગોઠવાયેલ SAML જૂથ એટ્રિબ્યુટ ખરેખર ધરાવે છે. કિંમત assertion અથવા ડિરેક્ટરી લુકઅપમાંથી કૉપિ કરો, વિકિ પૃષ્ઠમાંથી નહીં.

IAM જૂથ એ ભિન્ન નિયંત્રણ સપાટી છે. Client VPN endpoint સંચાલનની પરવાનગી IAM જૂથને વપરાશકર્તાનું VPN જૂથ બનાવતી નથી, અને access-group ફીલ્ડમાં IAM જૂથનું નામ પેસ્ટ કરવાથી તે AD SID કે SAML એટ્રિબ્યુટ કિંમતમાં રૂપાંતરિત થતું નથી.

બીજી ડિરેક્ટરીમાં સમાન નામનું જૂથ કંઈ સાબિત કરતું નથી. endpointની પ્રમાણીકરણ પદ્ધતિ અને તે જ સિસ્ટમમાં વપરાશકર્તાની સભ્યપદ કે assertion તપાસો.

સૌથી લાંબો પ્રીફિક્સ જીતે, 0.0.0.0/0 સહિત

અધિકૃતિ સૌથી લાંબા પ્રીફિક્સ મેળ દ્વારા મૂલવાય છે, અને બધા ગંતવ્યોનો નિયમ પ્રથમ નહીં પણ છેલ્લે મૂલવાય છે. Engineering માટે 10.46.0.0/16 નિયમ અને દરેક માટે 0.0.0.0/0 નિયમ ઉમેરો; Engineeringની બહારનો વપરાશકર્તા હજી પણ પહોળા નિયમ દ્વારા 10.46.20.10 સુધી પહોંચી શકશે નહીં.

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

ફેરફારોને ન્યાયપૂર્ણ મૂલવવા માટે નવું જોડાણ પણ જરૂરી છે. નિયમો સંપાદિત કર્યા પછી ક્લાયન્ટ ફરી જોડો, પછી ફરી પરીક્ષણ કરો.

અધિકૃતિને ડેટા માર્ગથી અલગ કરો

મેળ ખાતો નિયમ માર્ગ નથી. endpointને સંકળાયેલ સબનેટ અને ગંતવ્ય માટે રૂટ ટેબલ પ્રવેશ જરૂરી છે, અને લક્ષ્ય સંસાધનના સિક્યોરિટી જૂથે ટ્રાફિક સ્વીકારવો પડે. પરત ટ્રાફિક અને DNS પણ કામ કરવું જોઈએ.

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

જો IP સરનામું કામ કરે પણ હોસ્ટનામ ન કરે, તો અધિકૃતિને સ્પર્શતા પહેલાં resolver તપાસો. જો કોઈ રૂટ સરનામું આવરી ન લે, તો સંકળાયેલતા કે રૂટ ટેબલ સુધારો. જો પેકેટ આવે અને સેવા તેને નકારે, તો આગલું સ્ટેશન તે સેવાની નીતિ છે. અધિકૃતિ મેટ્રિક્સને બધા વપરાશકર્તાઓ સુધી લંબાવવાથી છુપાય છે કે આમાંથી કયો સ્તર ખરેખર તૂટેલો હતો.

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