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

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

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

הכלים הבסיסיים ביותר הם 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:

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

ההנחה היא:

• ל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 מציגה את כל התהליכים שממתינים במכונה הווירטואלית הזו, וצריך להופיע 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.