ASA નો દૂરસ્થ વપરાશકર્તા સબનેટ સુધી પહોંચે છે પણ એપ સુધી કેમ નહીં
રૂટ સાબિત કરે છે કે ટનલ કામ કરે છે, એ નહીં કે વપરાશકર્તાને એપ ખોલવાની પરવાનગી છે. સેશનને મળેલું ફિલ્ટર વાંચો, પછી મંજૂર અને નકારેલ જોડાણ ચકાસો.
તમારો વપરાશકર્તા જોડાય છે, સરનામું મેળવે છે, એપની સબનેટમાં સર્વરને પિંગ કરે છે, અને તો પણ તેના પરની સેવા ખોલી શકતો નથી. આ સંયોજન ASA પર સામાન્ય છે, કારણ કે સફળ ટનલ અને ઉપયોગી પરવાનગી જુદી જુદી સેટિંગ્સ નક્કી કરે છે. સ્પ્લિટ-ટનલ યાદીએ પસંદ કર્યું કે કયા લક્ષ્યો ટનલમાં દાખલ થયા; VPN ફિલ્ટર અને લક્ષ્યના પોતાના ઍક્સેસ નિયમો નક્કી કરે છે કે ડિક્રિપ્ટ થયેલી વિનંતી શું સુધી પહોંચી શકે. રૂટ યાદી પહોળી કરવાને બદલે ત્રણ નિર્ણયો ક્રમમાં પાર પાડો, જ્યાં સુધી કંઈક બદલાય નહીં.
ભૂલી શકાય તેવા ત્રણ નિર્ણયો
પ્રવેશ જણાવે છે કે વપરાશકર્તા ટનલ બનાવી શકે છે કે નહીં: ઓળખપત્રો, પ્રમાણપત્ર અને કોઈ પણ બીજું પરિબળ. માર્ગ પસંદગી જણાવે છે કે ક્લાયન્ટ કયા લક્ષ્યોને તે ટનલમાં મોકલે છે. અધિકૃતિ જણાવે છે કે ડિક્રિપ્ટ થયેલી વિનંતી સેવા સુધી પહોંચી શકે છે કે નહીં. ફક્ત ત્રીજું જ વપરાશકર્તા જે ભૂલ જણાવે છે તે ઉત્પન્ન કરે છે.
તેમને અલગ પાડવાનો ઝડપી રસ્તો એ પૂછવું છે કે ફેરફાર શું તોડશે. સ્પ્લિટ યાદીમાંથી રૂટ દૂર કરવાથી તે સબનેટ તરફનો ટ્રાફિક અટકે છે પણ કંઈ આપતું નથી; VPN ફિલ્ટરમાં ACE ઉમેરવાથી લક્ષ્ય મળે છે પણ ક્લાયન્ટ શું ટનલ કરે છે તે બદલાતું નથી.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
સેશનને ખરેખર મળેલું ફિલ્ટર વાંચો
તમે ધારો છો તે કન્ફિગરેશનથી નહીં, જીવંત સેશનથી શરૂ કરો. show vpn-sessiondb detail anyconnect સોંપાયેલ ગ્રુપ પોલિસી અને તે સેશન સાથે જોડાયેલ ફિલ્ટરનું નામ છાપે છે. જો ક્ષેત્ર ખાલી હોય, તો કોઈ ફિલ્ટર કંઈ લાગુ કરતું નથી અને અવરોધ બીજે ક્યાંકથી આવે છે.
પછી તે પોલિસી વાંચો જે મૂલ્યની માલિક છે, ડિફૉલ્ટ સહિત, કારણ કે ફિલ્ટર વારસાગત હોઈ શકે છે, તમે જ્યાં જુઓ છો ત્યાં લખાયેલું નહીં:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
સેશન પરના ફિલ્ટર નામની તમે હમણાં સંપાદિત કરેલી ACL સાથે સરખામણી કરો. સમાન નામની ACL જે વપરાશકર્તાને કદી મળી નથી તે તે સેશનની સ્રોત પોલિસી બદલી શકતી નથી, અને સાચું દેખાતું ફેરફાર અસરહીન હોવાનું આ સૌથી સામાન્ય કારણ છે.
પ્રાધાન્ય બાકીનું સમજાવે છે. ફિલ્ટર સેટિંગ માટે, DAP રેકોર્ડ વપરાશકર્તાનામ લક્ષણો પર પ્રાધાન્ય ધરાવે છે, અને વપરાશકર્તાનામ લક્ષણો ગ્રુપ પોલિસી પર પ્રાધાન્ય ધરાવે છે. જ્યારે સેશન અણધાર્યું ફિલ્ટર દર્શાવે, ત્યારે ગ્રુપને સ્પર્શ કરતા પહેલાં તે વપરાશકર્તા સાથે મેળ ખાતી DAP પોલિસી શોધો.
સ્પ્લિટ યાદી અને ફિલ્ટર અલગ ક્ષેત્રો છે
ASA 9.x પર ગ્રુપ પોલિસી split-tunnel-network-list અને vpn-filter ને જુદી જુદી સેટિંગ્સ તરીકે રાખે છે, અને 9.22 ગ્રુપ-પોલિસી માર્ગદર્શિકા તેમને એ જ કારણસર અલગ દસ્તાવેજ કરે છે. નેટવર્ક યાદી ક્લાયન્ટ માટે માર્ગદર્શન સંકેત છે; ફિલ્ટર ડિક્રિપ્ટ થયેલા ટ્રાફિક પર લાગુ થતી ઍક્સેસ કંટ્રોલ યાદી છે.
જ્યારે વપરાશકર્તાને સબનેટ પર એક જ HTTPS સેવા જોઈએ ત્યારે આ ભેદ મહત્ત્વનો છે. સબનેટને સ્પ્લિટ યાદીમાં મૂકો જેથી પેકેટ ટનલમાં પ્રવેશે, પછી ફિલ્ટરમાં ફક્ત તે સેવાને મંજૂરી આપો. રૂટ યાદી પહોળી કરવાથી કંઈ અધિકૃત થતું નથી, અને તેને સાંકડી કરવી એ અમલીકરણની પદ્ધતિ નથી.
તપાસો કે ઇન્ટરફેસ ACL પણ માર્ગમાં છે કે નહીં
ડિક્રિપ્ટ થયેલ દૂરસ્થ ઍક્સેસ ટ્રાફિક હંમેશા લોકો ધારે તેમ બાહ્ય ઇન્ટરફેસ ACLમાંથી પસાર થતો નથી. જ્યાં sysopt connection permit-vpn સક્ષમ છે, ત્યાં ASA તે ટ્રાફિક માટે તેનું દસ્તાવેજીકૃત VPN બાયપાસ લાગુ કરે છે, જ્યારે લાગુ પડતાં VPN ફિલ્ટર પછી પણ લાગુ રહે છે. સેટિંગને show run all sysopt વડે તપાસો, ટોપોલોજી આકૃતિમાંથી તર્ક કરવાને બદલે.
કોઈ પણ રીતે, લક્ષ્ય હોસ્ટનું પોતાનું ફાયરવૉલ અને એપની અધિકૃતિ માર્ગમાં રહે છે. TCP 443 ને મંજૂરી આપતો ASA નિયમ એપને વપરાશકર્તાને સ્વીકારવા મજબૂર કરતો નથી.
ફેરફારને નકારેલા જોડાણ સાથે પણ સ્વીકારો
ફક્ત મંજૂર પરીક્ષણ બહુ ઓછું સાબિત કરે છે, કારણ કે કાર્યરત ટનલ ફિલ્ટર હોય કે ન હોય, એ જ પ્રથમ પેકેટ ઉત્પન્ન કરે છે. ક્લાયન્ટથી ઇચ્છિત સેવા ખોલો, પછી બંધ રહેવાનું હોય તેવું લક્ષ્ય અજમાવો અને ખાતરી કરો કે તે યોગ્ય કારણસર નિષ્ફળ થાય છે.
ટિકિટ બંધ કરતી વખતે ચાર તથ્યો નોંધો: સ્વીકૃત ઓળખ, સેશનને ખરેખર મળેલી પોલિસી અને ફિલ્ટર, સ્પ્લિટ યાદીમાંના લક્ષ્યો, અને તે સ્રોત જે સુધી પહોંચવાની વપરાશકર્તાને પરવાનગી હતી. તે ચાર સમજાવે છે કે ટ્રાફિક ક્યાં નિયંત્રિત થાય છે, રૂટ યાદીને ફાયરવૉલમાં ફેરવ્યા વિના.
જો ફિલ્ટર મંજૂરી આપ્યા પછી પણ સેવા નકારે, તો હોસ્ટ પર જાઓ: સાંભળવાનું સરનામું, હોસ્ટ ફાયરવૉલ અને એપનું પોતાનું વપરાશકર્તા મેપિંગ. તે સમયે ટનલે તેનું કામ કર્યું, અને ASA પરના વધુ ફેરફારો ફક્ત જોખમ ઉમેરે છે.