ספירת VPN אתר FTD פעילות: איזה מספר התכוונתם?

לפני כתיבת משימת ה-Ansible, ענו על שאלה קטנה יותר: מה נספר? עמית מוגדר, הפעלת IKE, איגוד אבטחה של IPsec ורשומת מצב מנהרה במעקב הם ארבע יחידות שונות, וחידוש מפתחות או מספר רשתות מוגנות גורמים לסכומים שלהם להתפצל. אם לוח הבקרה וה-playbook לא מסכימים, בדרך כלל הם סופרים דברים שונים ולא שאחד מהם טועה.

ארבעה דברים שאנשים קוראים להם פעילים

עמית מוגדר הוא אובייקט טופולוגי: הוא קיים מפני שמישהו הגדיר אותו. הפעלת IKE היא יחס במישור הבקרה שיכול להיות למעלה בעוד ששום תעבורה לא זורמת. SA של IPsec הוא איגוד במישור הנתונים עבור זוג בוררים מסוים, ומנהרה אחת יכולה לשאת כמה כאלה. מצב מנהרה במעקב הוא פסק הדין התפעולי של הפלטפורמה עצמה, ובדרך כלל הוא הדבר הקרוב ביותר למה שמפעיל מתכוון כשהוא אומר שהמנהרה למעלה.

רק האחרון הוא בסיס סביר לספירה תפעולית. הראשון הוא מלאי תצורה, ודיווח עליו כפעיל הוא הדרך שבה לוח בקרה מציג ירוק עבור עמית שנמצא למטה מאז יום שלישי. החליטו איזו יחידה צרכן המספר צריך, ואז תייגו את המדד עם אותה יחידה בשמו שלו.

החלטה ראשונה: איזה מישור ניהול?

אם המכשיר מנוהל על ידי FDM, המשטח הרלוונטי הוא FTD REST API. אם הוא מנוהל על ידי FMC, ה-API הזה אינו תחליף חלופי, והאובייקטים חיים מאחורי ה-API של FMC עצמו. אשרו זאת לפני שתכתבו בקשה אחת, כי המישור השגוי מחזיר שגיאה סבירה שנראית כמו בעיית הרשאות.

עבור צי, התשובה קובעת גם היכן הספירה שייכת: לפי מכשיר דרך FDM, או לפי דומיין דרך FMC. אלה תחומים שונים והם מייצרים מספרים שונים עבור אותו צי.

החלטה שנייה: איזה משאב עונה?

לדוגמה המוגבלת לגרסה, מראה האובייקטים של FMC 7.3 API מתעד משאבי GET תחת נתיב health:

/api/fmc_config/v1/domain/{domainUUID}/health/tunnelstatuses
/api/fmc_config/v1/domain/{domainUUID}/health/tunnelsummaries

משאב מצב המנהרה תומך במסנני מכשיר ומצב, כולל TUNNEL_UP. זה נותן לכם משאב תפעולי אמיתי לבדיקה עבור אותה גרסה, ולא ניחוש לגבי שם שדה.

אשרו זמינות, הרשאות, פרמטרי בקשה וסכימת תגובה ב-API Explorer של ה-FMC הפרוס לפני יישום מנתח. תיעוד של גרסה אחת הוא נקודת התחלה, לא חוזה לזו שאתם מריצים.

כתבו את חוזה הספירה

נסחו את המדד במשפט אחד: רשומות מנהרה תפעוליות ייחודיות עבור מכשיר ודומיין מיועדים שמצבם המדווח הוא TUNNEL_UP. לאחר מכן תעדו כיצד מיוצגים מכשירים מיותרים ורשומות מרובות עבור אתר לוגי אחד, כי שני המקרים האלה קובעים אם המספר שלכם תואם לזה שבפגישה.

אל תשנו בשקט את היחידה מרשומת מנהרה לאתר מרוחק. אם העסק רוצה אתרים, מפו רשומות לאתרים באופן מפורש ופרסמו את המיפוי. ספירה שמגדירה את עצמה מחדש בשקט גרועה מאי-ספירה, כי אף אחד לא יכול לומר מתי היא השתנתה.

התייחסו למשאב הסיכום כנוחות רק לאחר שאישרתם מה הוא מסכם. הוא עשוי לצבור בדיוק את מה שאתם צריכים, או לענות על שאלה שונה במקצת. קראו את הסכימה שלו פעם אחת, רשמו את ההבדל, והשתמשו במשאב המצב אם לא ניתן להסביר את הסיכום. סיכום שאינכם מבינים הוא מספר שאינכם יכולים להגן עליו בסקירה.

תנו לזרימת העבודה לשמר את אי-הוודאות

השתמשו ב-HTTPS API המאושר, אמתו את התעודה, החזיקו אסימונים מחוץ לפלט המשימה, ואחזרו את ההיקף עם המסנן והעימוד שהגרסה תומכת בהם. לאחר מכן אמתו את הסכימה לפני חישוב משהו.

fetch intended domain/device runtime records
validate response, completeness and freshness
deduplicate by the documented tunnel identity
count records matching the approved up-state definition
report count with scope, timestamp and metric unit

זהו פסאודו-קוד של זרימת עבודה, לא playbook נבדק. קחו את שמות השדות האמיתיים מה-API המותקן במקום להמציא מפתח JSON בשם active.

הכלל החשוב הוא התנהגות כשל: שגיאת הרשאה, משאב לא נתמך, דגימה מיושנת או סט עמודים חלקי חייבים להפיק unknown או error, ולעולם לא אפס מוצלח. אפס שמשמעותו לא הצלחתי לשאול הוא הסוג היקר ביותר של טעות.

אמתו מול התצוגה של הפלטפורמה עצמה

השוו את התוצאה הראשונה לתצוגת ניטור ה-VPN של הגרסה עבור אותו מכשיר ואותו רגע. כשהם שונים, גלו איזו יחידה כל אחד משתמש בה לפני שתשנו את ה-playbook.

שמרו הקשר שאינו סודי לכל הרצה: היקף, חותמת זמן, יחידת המדד ומספר הרשומות. מראה האובייקטים של FMC 7.3 API הוא המקור לנתיבי המשאבים שלמעלה, וה-API Explorer בפריסה שלכם הוא המקור לכל השאר.