פרסום שירות פנימי דרך VPN מאתר לאתר של ASA
חמש בדיקות מסודרות לחשיפת שירות פנימי דרך VPN מאתר לאתר של ASA: טווח מוגן, מודל מקור, תרגום, היקף יציאה, נתיב התשובה.
פרסום שירות שחי מאחורי VPN מאתר לאתר הוא משימה אחת עם חמישה נקודות כשל, והן נכשלות בסדר קבוע. המנהרה עולה, התרגום מתאים, הסניף עונה והתשובה חוזרת באותו נתיב. כשאחד מאלה שגוי, הדפדפן מציג אותו דבר: חיבור שתלוי או מתאפס. עברו על הרשימה מלמעלה למטה ועצרו בבדיקה הראשונה שנכשלת.
בדיקה 1: המנהרה מגנה על כתובת המקור
התחילו ממנהרה שכבר מעבירה תעבורה, ואז ודאו שהכתובת שאתם מתכננים לפרסם נמצאת בתוך הטווח המוגן. ב-ASA הטווח הזה מגיע מה-ACL של ההצפנה או מהמסלולים של VTI, והוא חייב לכסות את הכתובת האמיתית של המקור ולא את תת-הרשת שהסניף משתמש בה לניהול. בורר שמפספס את המקור נותן לכם מנהרה שעולה וזרימה שלעולם לא נכנסת אליה.
ודאו זאת עם מוני המנהרה וטבלת המסלולים לפני שאתם נוגעים בתרגום. אם המקור אינו נגיש מהמרכז דרך המנהרה, שום דבר בהמשך הרשימה לא יכול לתקן זאת.
עצרו כאן אם הטווח המוגן וכתובת המקור אינם תואמים.
בדיקה 2: החליטו איזה מקור יראה הסניף
הסניף רואה או את כתובת הלקוח המקורית או כתובת מתורגמת, והבחירה הזו קובעת את נתיב החזרה. שמירה על כתובת הלקוח נקראת נקי יותר ביומני המקור, אבל אז הסניף חייב לשלוח תשובות ללקוחות ציבוריים חזרה דרך המנהרה; מסלול ברירת מחדל רגיל של האינטרנט שולח אותן לכיוון השני והחיבור מת בכיוון אחד. תרגום המקור לכתובת שהסניף כבר מנתב דרך המנהרה מסיר את הדרישה הזו.
התרגום גם משנה מה המקור יכול לרשום ביומן ועם מה כללים מבוססי מקור יכולים להתאים. אם היישום צריך לדעת את האדם שמאחורי בקשה, זה שייך לפרוקסי הפוך מאומת, לא להחלטת NAT.
בדיקה 3: כתבו את התרגום מול הממשקים האמיתיים
ASA מעריך כללי תרגום לפי הסדר ומדווח איזה התאים, ולכן זוג הממשקים בתוך הכלל אינו קוסמטי. כלל שנכתב לנתיב מבחוץ פנימה לא יתאים לזרימה שהכניסה והיציאה שלה שונות מאלה שהנחתם.
לנתיב שאתם בונים יש ארבעה קטעים, וכל הארבעה חייבים להתיישב:
| Leg | Source | Destination |
|---|---|---|
| Request from the internet | 198.51.100.25 | 203.0.113.20:443 |
| After destination translation | 198.51.100.25 | 10.60.20.10:443 |
| After source translation toward the tunnel | 10.10.250.10 | 10.60.20.10:443 |
| Branch reply | 10.60.20.10 | 10.10.250.10 |
| Restored reply to the client | 203.0.113.20 | 198.51.100.25 |
התייחסו לטווחים בטבלה הזו כממלאי מקום. החשוב הוא שהטאפל אחרי התרגום הוא כתובת שהסניף מקבל דרך המנהרה, ושמיפוי ההפוך קיים במצב NAT כדי שהתשובה תשוחזר ביציאה.
בדיקה 4: הגבילו את כלל הגישה ליציאה המפורסמת
פרסמו את היציאה, לא את המארח. כלל שמתיר את המקור בכל שירות הופך יישום מפורסם אחד לנתיב לכל מה שהמקור מריץ, כולל ממשק הניהול שהחזקתם מחוץ לאינטרנט בכוונה. התירו את היציאה המפורסמת מהמקור המתורגם אל המקור, והשאירו שירותי ניהול בנתיב שלהם דרך VPN בלבד.
בדקו את סדר הכללים באותו זמן. הרשאה רחבה שיושבת מעל הכלל הספציפי שלכם הופכת את הכלל הספציפי לבלתי נראה.
בדיקה 5: עקבו אחרי בקשה אחת והתשובה שלה
אל תתחילו בדפדפן, כי דפדפן מסתיר איזה קטע נכשל. עקבו אחרי הזרימה במרכז וקראו את התוצאה לפני שתשנו משהו.
packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2lהמעקב נוקב בשם התרגום שהתאים, בכלל הגישה שהתיר או דחה את הזרימה, ובשאלה אם החבילה נותבה למנהרה. אם הוא מראה שהזרימה יוצאת מממשק שלא ציפיתם לו, זוג הממשקים בכלל ה-NAT שגוי. אם הוא מראה דחייה, סדר הכללים שגוי. אם היא מגיעה למנהרה אבל המקור לא עונה לעולם, הבעיה היא נתיב החזרה של הסניף.
אחר כך שלחו בקשה אמיתית אחת מבחוץ וודאו שהתשובה חוזרת באותה מנהרה. רשמו את הרשומה המפורסמת, התרגום, זוג הכתובות המוגן ונתיב החזרה כרישום הפרסום.