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

‫MySQL   |  PostgreSQL   |  PostgreSQL ל-AlloyDB

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

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

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

פינג

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

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

Traceroute

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

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

אם traceroute לא מצליח להשלים את הפעולה, יכול להיות שתוכלו להבין איפה הוא הפסיק. מחפשים את כתובת ה-IP האחרונה שמופיעה ב-traceroute output ומבצעים חיפוש בדפדפן של 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 console.

   כניסה לדף Cloud SQL Instances

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

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

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

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

כל הפעילות של יציאת נתונים מקומית

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

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

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

אם המארח המרוחק מריץ מסד נתונים של MySQL, למשל, אמורה להיות לכם אפשרות להשתמש ב-telnet כדי להתחבר אליו ביציאה 3306: telnet 35.193.198.159 3306.

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

Trying 35.193.198.159...

Connected to 35.193.198.159. .

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

Trying 35.193.198.159...

^C. .

Cloud Logging

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

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

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

המסוף

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

gcloud

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

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

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

חיבורים למכונת Cloud SQL באמצעות כתובת IP פרטית מקבלים הרשאה אוטומטית לטווח כתובות RFC 1918. צריך להגדיר ב-Cloud SQL טווחי כתובות שאינם RFC 1918 כרשתות מורשות. בנוסף, צריך לעדכן את הקישור בין רשתות שכנות (peering) ל-Cloud SQL כדי לייצא נתיבים שאינם RFC 1918. לדוגמה: gcloud compute networks peerings update cloudsql-mysql-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] – אמורה להופיע בקשה להזנת סיסמה של MySQL (משהו כמו 5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnection)
   • [db_client] -h[source_db_host_or_ip] -P[source_db_port] – צריכה להופיע הודעה על דחיית הגישה (משהו כמו ERROR 1045 (28000): Access denied for user...)

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

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] – אמורה להופיע ההנחיה להזנת סיסמת mysql (משהו כמו 5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnection)
   • ‫[db_client] -h127.0.0.1 -P[tunnel_port] – צפו לראות שהגישה נדחתה (משהו כמו ERROR 1045 (28000): Access denied for user...)

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

Cloud SQL DB ---> source DB

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

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

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

1. נכנסים לדף VPC networks במסוף Google Cloud .

2. בוחרים את רשת ה-VPC שרוצים להשתמש בה.

3. בוחרים באפשרות גישה לשירותים פרטיים > הקצאת טווחי כתובות IP לשירותים.

4. מאתרים את טווח כתובות ה-IP הפנימיות שמשויך לחיבור שנוצר על ידי servicenetworking-googleapis-com.

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