מדוע משתמש מרוחק ב-ASA מגיע לרשת המשנה אך לא לאפליקציה
מסלולים מוכיחים שהמנהרה עובדת, לא שהמשתמש רשאי לפתוח את האפליקציה. קראו את המסנן שהסשן קיבל, ואז בדקו חיבור מותר וחיבור חסום.
המשתמש שלכם מתחבר, מקבל כתובת, מבצע פינג לשרת ברשת המשנה של האפליקציה, ובכל זאת אינו יכול לפתוח את השירות שעליה. השילוב הזה נורמלי ב-ASA, כי מנהרה מוצלחת והרשאה שמישה נקבעות על ידי הגדרות שונות. רשימת המנהרה המפוצלת בחרה אילו יעדים נכנסו למנהרה; מסנן VPN וכללי הגישה של היעד עצמו קובעים מה הבקשה המפוענחת רשאית להשיג. עברו על שלוש ההחלטות לפי הסדר במקום להרחיב את רשימת המסלולים עד שמשהו משתנה.
שלוש החלטות שקל לבלבל ביניהן
הקבלה עונה אם המשתמש רשאי להקים את המנהרה בכלל: אישורים, תעודה וכל גורם שני. בחירת מסלול עונה אילו יעדים הלקוח שולח לתוך המנהרה הזו. הרשאה עונה אם הבקשה המפוענחת רשאית להשיג את השירות. רק השלישית מייצרת את השגיאה שהמשתמש מדווח עליה.
דרך מהירה להבחין ביניהן היא לשאול מה שינוי היה שובר. הסרת מסלול מרשימת הפיצול עוצרת תעבורה לרשת המשנה הזו בלי להעניק דבר; הוספת ACE למסנן VPN מעניקה יעד בלי לשנות מה הלקוח מעביר במנהרה.
| 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 במקום להסיק מתרשים הטופולוגיה.
בכל מקרה, חומת האש של מארח היעד וההרשאה של האפליקציה נשארות בנתיב. כלל ASA שמתיר TCP 443 אינו גורם לאפליקציה לקבל את המשתמש.
קבלו את השינוי גם עם חיבור חסום
בדיקה מותרת לבדה מוכיחה מעט מאוד, כי מנהרה עובדת מייצרת את אותה חבילה ראשונה בין אם קיים מסנן ובין אם לא. פתחו את השירות המיועד מהלקוח, ואז נסו יעד שצריך להישאר סגור וודאו שהוא נכשל מהסיבה הנכונה.
רשמו ארבע עובדות כשאתם סוגרים את הפנייה: הזהות שהתקבלה, המדיניות והמסנן שהסשן קיבל בפועל, היעדים ברשימת הפיצול והמשאב שהותר למשתמש להשיג. ארבעת אלה מסבירים היכן התעבורה נשלטת בלי להפוך רשימת מסלולים לחומת אש.
אם השירות עדיין מסרב לאחר שהמסנן מתיר אותו, עברו למארח: כתובת האזנה, חומת האש של המארח ומיפוי המשתמשים של האפליקציה עצמה. המנהרה עשתה את שלה בשלב הזה, ושינויים נוספים ב-ASA רק מוסיפים סיכון.