ניפוי באגים בקישוריות

ניפוי באגים בקישוריות

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

הכלים הבסיסיים ביותר הם ping ו-traceroute.

פינג

‫Ping מבצע בדיקה בסיסית כדי לקבוע אם היעד ("המארח המרוחק") זמין מהמקור. ‫Ping שולח חבילת ICMP Echo Request למארח מרוחק, ומצפה לקבל בחזרה ICMP Echo Reply. אם ping לא מצליח, אין מסלול מהמקור ליעד. עם זאת, הצלחה לא אומרת שהחבילות יכולות לעבור, אלא רק שבאופן כללי אפשר להגיע למארח המרוחק.

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

Traceroute

Traceroute בודק את המסלול המלא של חבילות הרשת ממארח אחד למארח אחר. הוא מציג את כל השלבים ("הצעדים") שהחבילה עוברת בדרך, וכמה זמן נמשך כל שלב. אם החבילה לא מגיעה עד ליעד, הפקודה traceroute לא מסתיימת, אלא מסתיימת בסדרה של כוכביות. במקרה כזה, חפשו את כתובת ה-IP האחרונה שהפקודה הצליחה להגיע אליה. כאן הקישוריות נותקה.

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

אם traceroute לא הושלם, יכול להיות שתוכלו להבין איפה הוא נעצר. מוצאים את כתובת ה-IP האחרונה שמופיעה בפלט של traceroute, ומחפשים בדפדפן את who owns [IP_ADDRESS]. יכול להיות שהבעלים של הכתובת יופיע בתוצאות, אבל לא בטוח. בכל מקרה, שווה לנסות.

mtr

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

איתור כתובת ה-IP המקומית

אם אתם לא יודעים את הכתובת המקומית של המארח, הריצו את הפקודה ip -br address show. ב-Linux, מוצגים ממשק הרשת, הסטטוס של הממשק, כתובת ה-IP המקומית וכתובות ה-MAC. לדוגמה: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64.

אפשר גם להריץ את ipconfig או את ifconfig כדי לראות את הסטטוס של ממשקי הרשת.

איתור כתובת ה-IP היוצאת

אם אתם לא יודעים מהי כתובת ה-IP שבה מסדי הנתונים של המקור והיעד משתמשים כדי לתקשר זה עם זה (כתובת ה-IP היוצאת), בצעו את השלבים הבאים:

1. נכנסים לדף SQL Instances במסוף Google Cloud .

   כניסה לדף Cloud SQL Instances

2. לוחצים על השם של המכונה שמשויכת למשימת ההעברה שמנפים בה באגים.
3. גוללים למטה עד שמופיע החלונית Connect to this instance. בחלונית הזו מופיעה כתובת ה-IP היוצאת.

פתיחת יציאות מקומיות

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

לדוגמה, אם יש לכם מסד נתונים של PostgreSQL שפועל, יציאה 5432 צריכה להיות פעילה ולהאזין. ל-SSH, אמורה להופיע היציאה 22.

כל הפעילות ביציאה המקומית

משתמשים בפקודה netstat כדי לראות את כל הפעילות ביציאה המקומית. לדוגמה, הפקודה netstat -lt מציגה את כל היציאות הפעילות כרגע.

מתחברים למארח המרוחק באמצעות telnet

כדי לוודא שאפשר להתחבר למארח המרוחק באמצעות TCP, מריצים את הפקודה telnet. ‫Telnet מנסה להתחבר לכתובת ה-IP וליציאה שציינתם.

לדוגמה, אם המארח המרוחק מריץ מסד נתונים של PostgreSQL, אתם אמורים להיות מסוגלים להתחבר אליו באמצעות telnet ביציאה 5432: telnet 35.193.198.159 5432.

אם הפעולה בוצעה בהצלחה, תראו את ההודעה הבאה:

Trying 35.193.198.159...
Connected to 35.193.198.159.

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

Trying 35.193.198.159...
^C

אימות לקוח

אימות הלקוח נשלט על ידי קובץ תצורה שנקרא pg_hba.conf (HBA מייצג אימות מבוסס-מארח).

מוודאים שהקטע של חיבורי הרפליקציה בקובץ pg_hba.conf במסד הנתונים של המקור מעודכן, כדי לקבל חיבורים מטווח כתובות ה-IP של ה-VPC של Cloud SQL.

Cloud Logging

‫Database Migration Service ו-Cloud SQL משתמשים ב-Cloud Logging. למידע מלא, קראו את המסמכים של Cloud Logging ועיינו בשאילתות לדוגמה של Cloud SQL.

צפייה ביומנים

אפשר לראות את היומנים של מכונות Cloud SQL ושל פרויקטים אחרים ב- Google Cloud, כמו Cloud VPN או מכונות Compute Engine. כדי לראות את רשומות היומן של המכונה ב-Cloud SQL:

המסוף

1. כניסה לדף Logs Explorer
2. בוחרים פרויקט קיים ב-Cloud SQL בחלק העליון של הדף.
3. בכלי ליצירת שאילתות, מוסיפים את הפרטים הבאים:
   • משאב: בוחרים באפשרות מסד נתונים של Cloud SQL. בתיבת הדו-שיח, בוחרים מכונה של Cloud SQL.
   • שמות היומנים: גוללים לקטע Cloud SQL ובוחרים את קובצי היומן המתאימים למכונה. לדוגמה:
     • cloudsql.googleapis.com/postgres.log
   • חומרה: בוחרים רמת יומן.
   • טווח תאריכים: בוחרים הגדרה קבועה מראש או יוצרים טווח תאריכים בהתאמה אישית.

gcloud

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

gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/postgres.log" --limit=10

כתובות IP פרטיות

חיבורים למכונה של Cloud SQL באמצעות כתובת IP פרטית מאושרים באופן אוטומטי לטווחי כתובות RFC 1918. צריך להגדיר טווחי כתובות שאינם RFC 1918 ב-Cloud SQL כרשתות מורשות. צריך גם לעדכן את קישור הרשתות השכנות (peering) ל-Cloud SQL כדי לייצא נתיבים שהם לא RFC 1918. לדוגמה: gcloud compute networks peerings update cloudsql-postgres-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT

טווח כתובות ה-IP‏ 172.17.0.0/16 שמור לרשת הגשר של Docker. לא תהיה אפשרות לגשת למכונות של Cloud SQL שנוצרו עם כתובת IP בטווח הזה. חיבורים מכל כתובת IP בטווח הזה למכונות Cloud SQL באמצעות כתובת IP פרטית ייכשלו.

פתרון בעיות ב-VPN

Google Cloud פתרון בעיות ב-Cloud VPN

פתרון בעיות במנהרת SSH הפוכה

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

כדי לעשות את זה, צריך להגדיר את הדברים הבאים:

Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

הערה: למרות ש-Database Migration Service מעביר נתונים ממקור ליעד, צריך להפעיל את הקישוריות מהיעד למקור.

ההנחה היא:

• לCompute Engine VM bastion יש גישה אל Cloud SQL DB.

• ל-source network bastion יש גישה ל-source DB (באמצעות התאמת רשתות בין הרשת של Cloud SQL לרשת של המכונה הווירטואלית ב-Compute Engine).

לאחר מכן מגדירים מנהרת SSH מהמכונה source network bastion למכונה Compute Engine VM bastion, שמנתבת את כל החיבורים הנכנסים ליציאה כלשהי במכונה Compute Engine VM bastion דרך המנהרה למכונה source DB.

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

source network bastion ---> source DB

1. מתחברים אל source network bastion באמצעות SSH, או מהטרמינל אם מדובר במכונה המקומית.
2. בודקים את הקישוריות למסד הנתונים של המקור באחת מהשיטות הבאות:
   • ‫telnet [source_db_host_or_ip] [source_db_port] – אמורות להופיע מחרוזות החיבור של telnet, שמסתיימות ב-Connected to x.x.x.x.
   • ‫psql -h [source_db_host_or_ip] -p [source_db_port] -U [username] -d [database_name] – אמורה להופיע בקשה להזנת סיסמה או הודעה על דחיית הגישה.

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

Compute Engine VM bastion ---> source DB

1. מבצעים SSH אל Compute Engine VM bastion (באמצעות gcloud compute ssh VM_INSTANCE_NAME).
2. בודקים את הקישוריות למסד הנתונים של המקור באחת מהשיטות הבאות:
   • ‫telnet 127.0.0.1 [tunnel_port] – אמורות להופיע מחרוזות החיבור של telnet, שמסתיימות ב-Connected to x.x.x.x.
   • psql -h 127.0.0.1 -p [tunnel_port] -U [username] -d [database_name] – צפויה להופיע בקשה להזנת סיסמה או הודעה על דחיית הגישה.

אם הבדיקה נכשלת, צריך לוודא שהמנהרה פועלת כמו שצריך. הרצת sudo netstat -tupln מציגה את כל התהליכים שממתינים ב-VM הזה, וצריך לראות את sshd listening on the tunnel_port.

Cloud SQL DB ---> source DB

הדרך הכי טובה לבדוק את זה היא testing the migration job מ-Database Migration Service. אם הבדיקה נכשלת, סימן שיש בעיה בקישור בין רשתות VPC שכנות (peering) או בניתוב בין הרשת של Cloud SQL לבין הרשת של Compute Engine VM bastion.

חומת האש של שרת מסד הנתונים במקור צריכה להיות מוגדרת כך שתאפשר את כל טווח כתובות ה-IP הפנימיות שהוקצה לחיבור לשירות הפרטי של רשת ה-VPC, שבה מכונת היעד של Cloud SQL תשתמש בתור השדה privateNetwork של הגדרות ה-ipConfiguration שלה.

כדי למצוא את טווח כתובות ה-IP הפנימיות במסוף:

1. נכנסים לדף VPC networks במסוף Google Cloud .
2. בוחרים את רשת ה-VPC שבה רוצים להשתמש.
3. בוחרים באפשרות Private services access > Allocated IP ranges for services.
4. מוצאים את טווח כתובות ה-IP הפנימיות שמשויך לחיבור שנוצר על ידי servicenetworking-googleapis-com.

אפשר גם לראות את התנועה בין המכונה של Cloud SQL לבין המכונה הווירטואלית של Compute Engine במסוף Cloud Logging בפרויקט Cloud VPN gateway. ביומנים של המכונה הווירטואלית ב-Compute Engine, חפשו תנועה שמגיעה מהמכונה של Cloud SQL. ביומנים של מכונת Cloud SQL, מחפשים תנועה מהמכונה הווירטואלית של Compute Engine.