פתרון בעיות נפוצות

נתמך ב:

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

בעיה של אי-התאמה במפתחות

הבעיה הזו מתרחשת כשהמפתחות הפרטיים ב-Google Security Operations ובסוכן המרוחק לא תואמים. כדי לפתור את הבעיה, צריך לוודא שהמפתח במשאבי הסוכן זהה למפתח ב-Siemplify agent_db.

כשל במחבר המרוחק

אם מחבר מרחוק נכשל, פועלים לפי השלבים הבאים:

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

ההתקנה נכשלה: מערכת הפעלה של מארח שלא נתמכת או חוסר תאימות בגלל סוף החיים (EOL)

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

  1. מוודאים שבסביבת המארח לא פועלת מערכת הפעלה מדור קודם, כי יכול להיות שאין בה הוקים מודרניים לקריאות מערכת.
  2. מארחים מחדש את סביבת הסוכן בהפצת Linux לארגונים עם הגרסה הרשמית העדכנית.
  3. מוודאים שהמארח הוא פלטפורמה נתמכת: Debian 12 (בסיס רשמי), RHEL 8.7:

    בודקים את /etc/os-release: מריצים את הפקודה הבאה ומחפשים את NAME= ו-VERSION_ID=:

    cat /etc/os-release
    • ב-Debian 12: מחפשים את NAME="Debian GNU/Linux" ואת VERSION_ID="12".
    • ב-RHEL 8.7: מחפשים את NAME="Red Hat Enterprise Linux" ו-VERSION_ID="8.7".

הגדרת מאגר שולפת את השכבה התפעולית הקודמת במקום את הגרסה העדכנית ביותר

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

  • ב-Docker:

    docker pull us-docker.pkg.dev/siem-ar-public/images/agent:latest

  • ל-Podman:

    podman pull us-docker.pkg.dev/siem-ar-public/images/agent:latest

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

כשל בפריסת סוכן Docker

אם הפריסה של Docker נכשלת, פועלים לפי השלבים הבאים:

  1. מסירים את מאגר Docker:

    1. מריצים את הפקודה הבאה כדי להציג את רשימת הקונטיינרים הפועלים:

      docker ps 

    2. מריצים את הפקודה הבאה כדי להסיר את הקונטיינרים שנכשלו:

      docker rm -f container_id_or_name
  2. הסרת תמונות:

    1. מריצים את הפקודה הבאה כדי להציג את רשימת התמונות:

      docker images 

    2. מריצים את הפקודה הבאה כדי להסיר את התמונה:

      docker rmi image_id_or_name
  3. הסרת אמצעי אחסון:

    1. מריצים את הפקודה הבאה כדי להציג את עוצמות הקול:

      docker volume ls

    2. מריצים את הפקודה הבאה כדי להסיר את אמצעי האחסון:

      docker volume rm volume_name
  4. פורסים מחדש את הסוכן. מידע נוסף זמין במאמר יצירת סוכן באמצעות Docker.

הסוכן נתקע בסטטוס 'בהמתנה לנציג'

אם הסוכן נפרס בהצלחה אבל הסטטוס נשאר 'בהמתנה לסוכן', פועלים לפי השלבים הבאים כדי לפתור את הבעיה:

  1. בודקים את הקישוריות של המארח: בודקים את הקישוריות לאינטרנט של המכונה המארחת של הסוכן (לדוגמה, curl www.google.com או ping 8.8.8.8). אם הבדיקה נכשלת, הבעיה היא בחיבור לאינטרנט של המארח.

  2. בדיקת הקישוריות של הקונטיינר: אם הבדיקה של המארח עוברת, מזינים את מעטפת הקונטיינר באמצעות docker exec -it container_ID bash ובודקים מחדש את הקישוריות. אם אין קישוריות בקונטיינר, מפעילים מחדש את שירות Docker במחשב המארח (service docker restart).

    1. מריצים את הפקודה הבאה:

      docker exec -it bash

    2. בודקים שוב את הקישוריות כמו קודם.
    3. אם אין קישוריות, מריצים את הפקודה הבאה כדי להפעיל מחדש את שירות Docker ממכונת המארח (לא מהקונטיינר):

      service docker restart

    4. מריצים את הפקודה הבאה כדי להפעיל מחדש את הקונטיינר:

      docker start

  3. בדיקת יומני מאגרי תגים לאיתור שגיאות

    אם השלב הקודם לא עזר, והסטטוס של הסוכן הוא עדיין 'בהמתנה לסוכן' אחרי רענון הדף Remote agent ב-Google SecOps, צריך להתחבר מחדש לקונטיינר ולשלוף את היומנים.

    1. מחפשים את היומנים בספרייה /var/log/SiemplifyAgent/.
    2. כדי לזהות את שורש הבעיה, חפשו שגיאות בקובצי היומן.

בעיות ברשת DNS

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

טעינת קובץ האימג' של Docker נכשלת (העברת נתונים ב-IP4 מושבתת)

אם מופיעה שגיאה ב-CLI כשמנסים לטעון קובץ אימג' של Docker (מערכת) או סוכן של Google SecOps, יכול להיות שהעברת IP4 מושבתת. כדי להפעיל את התכונה הזו ולהפעיל מחדש את הסוכן, פועלים לפי השלבים הבאים:

  1. מוסיפים את השורה הבאה לקובץ /etc/sysctl.conf:

    net.ipv4.ip_forward=1 שימו לב שתצטרכו להשתמש בכלי לעריכת קבצים (לדוגמה, nano). כך משתמשים בו: yum install nano -y

  2. מריצים את הפקודה הבאה כדי להפעיל מחדש את שירות הרשת:

    systemctl restart network

  3. מריצים את הפקודה הבאה כדי להפעיל מחדש את שירות Docker:

    sudo systemctl restart docker

  4. מריצים את הפקודה הבאה כדי לבדוק אם הקונטיינר פועל:

    docker ps

  5. אם מאגר התגים לא פועל, מריצים את הפקודה הבאה כדי להציג רשימה של כל מאגרי התגים (כולל אלה שהופסקה הפעולה שלהם):

    docker ps -a

  6. אם הקונטיינר מופיע ברשימה אבל הוא במצב עצירה, מריצים את הפקודה הבאה כדי להפעיל אותו:

    docker start container_id_or_name
  7. אם הסוכן או המערכת עדיין לא פועלים אחרי הפעלה מחדש של Docker והקונטיינר:

    1. מריצים את הפקודה הבאה כדי לעצור את הקונטיינר:

      docker stop container_id_or_name

    2. מריצים את הפקודה הבאה כדי למחוק את הקונטיינר:

      docker rm container_id_or_name

    3. מריצים את הפקודה הבאה כדי למחוק את התמונה:

      docker rmi image_name
    4. טוענים את התמונה שוב.

שגיאה אחרי כיבוי או הפעלה מחדש של הסוכן

מריצים את הפקודה הבאה כדי לאלץ את ההפעלה של סוכן ההתקנה:
systemctl start supervisord

מריצים את הפקודה הבאה כדי להפעיל בכוח את סוכן Docker:‏
docker start

הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.