שאילתת מסד נתונים נתקעת מעל IPsec: סידור מחדש של UDP או TCP?
שאילתה שנתקעת אחרי לחיצת יד נקייה מצביעה על פנים נתיב המנהרה. שלושה תנאים מכריעים אם לתקן את הנתיב או לחזור ל-TCP בפורט 443.
שאילתה שנתקעת אחרי לחיצת יד TCP אינה בעיית ניתוב. תקלות נתיב מפילות את לחיצת היד, ולכן הפעלה שמתבססת ואז משתתקת מצביעה על פנים הנתיב: בדיקה, MTU, או האופן שבו מנות ה-UDP של המנהרה מגיעות. ההחלטה שלפניכם היא אם לתקן את הנתיב הזה או להעביר את המנהרה ל-TCP. שלושה תנאים מכריעים בכך, ואף אחד מהם אינו עוסק במסד הנתונים.
סווגו את התקיעה לפני שאתם מאשימים את המנהרה
ארבע תוצאות נראות אותו דבר למשתמש ומשמעותן שונה לגמרי למהנדס.
| What the client sees | What it rules out |
|---|---|
| Connection refused | Nothing is listening on the address and port the client reached |
| Timeout before the handshake | A filter, a missing route, or the wrong address |
| Handshake completes, query hangs | The session exists, so look at inspection, MTU and packet order |
| Stalls that recover on retry | Often reordering, or a state table entry expiring |
רק שתי השורות האחרונות מצדיקות זמן על המנהרה. חיבור שנדחה דרך VPN הוא בדרך כלל מסד הנתונים שמאזין רק על loopback, וזו בעיית מאזין, ופסק זמן לפני לחיצת היד הוא מסנן או נתיב. אף אחד מהם לא משתפר על ידי שינוי הכימוס.
כתבו את הסיווג בכרטיס קודם. זה הצעד הזול ביותר והוא מסיר את רוב מרחב החיפוש.
שלושה תנאים שמכריעים בין UDP ל-TCP
תעבורת IPsec מכומסת נוסעת על UDP, ו-UDP נותן לנתיב חופש לסדר מחדש ולהפיל בלי לומר לאיש. כשסידור מחדש דוחף מנות אל מחוץ לחלון מניעת החזרה של המנהרה, הן נזרקות בשקט והפעלת ה-TCP הפנימית פשוט ממתינה. זה המנגנון שמאחורי לחיצת יד שמצליחה ושאילתה שלעולם אינה חוזרת.
תיקון הנתיב או חזרה ל-TCP תלוי בשלושה דברים. ראשית, האם יש אובדן מנות אמיתי בנתיב, או רק סידור מחדש? שנית, האם אתם יכולים לשנות היכן הבדיקה מתבצעת, או להוציא את המנהרה הזו מהרכיב שמסדר מחדש? שלישית, האם העומס רגיש לדפוס התקיעה, למשל הפעלות מרובות ומרובבות שחולקות קישור אחד?
אם התשובה הראשונה היא אובדן והשנייה לא,TCP בפורט 443 הוא החלופה הפרגמטית. אם התשובה השנייה היא כן, תקנו את הנתיב והשאירו UDP.
קראו את הרשומה של חומת האש, לא את שגיאת היישום
היישום מדווח על פסק זמן, וזה לא אומר דבר על הסיבה. היומן של חומת האש עצמה הוא המקום שבו ההפלה או החסימה מופיעה, אז סננו לפי כתובות מסד הנתונים והיישום וחפשו גם הפלות וגם אישורים.מודולי מניעת איומים יכולים להפיל מנות בלי ליצור שגיאה ברמת היישום, וזה בדיוק הצורה של שאילתה שנתקעת. שתיקה ביומן היא גם נתון: היא מצביעה על משהו שלא מתעד, כמו סידור מחדש.
בדקו גם את האשכול. אשכול שהוגדר שגוי עלול להחזיק הפעלה בטבלת המצבים באחד החברים בעוד המנות הולכות בנתיב של חבר אחר, כך שהתשובות מגיעות למקום שאין בו מצב. תקיעות כאלה נראות אקראיות ואינן מתואמות עם עומס.
השוו את שני הקצוות לפני שתשנו משהו, והשוו סדר הגעה ולא מספר מנות:
tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcapמה TCP בפורט 443 באמת עולה לכם
העברת המנהרה ל-TCP מסירה את תסמין הסידור מחדש, כי ה-middlebox רואה כעת זרם מסודר. היא גם יוצרת TCP מעל TCP. החיבור החיצוני משדר מחדש את מה שהחיבור הפנימי כבר שידר מחדש, ואובדן אחד יכול לעצור את כל ההפעלות המרובבות בבת אחת. בנתיב נקי זה בלתי נראה. בנתיב עם אובדן התרופה גרועה מהתסמין.
ההחלפה מקובלת כשהחלופה היא היעדר קישוריות, ויש לתעד אותה כחריגה עם אחראי ולא לספוג אותה כשגרה.
תעדו את התעבורה, הפורט, שאילתת דוגמה והתוצאה הנמדדת, וגם את התאריך. בלי הרשומה הזו המהנדס הבא חוזר על הניסוי, והחריגה הופכת בשקט לארכיטקטורה.
השאירו את ההחלטה ניתנת לבדיקה חוזרת
אבחון נתיב מתיישן רע. ה-middlebox מוחלף, תצורת המודול משתנה, הקישור משודרג, והסיבה ל-TCP בפורט 443 נעלמת בעוד התצורה נשארת. שימו תאריך סקירה על החריגה ונקבו בתנאי שיאפשר לכם לחזור ל-UDP.
בדקו את שתי התעבורות עם שאילתה קטנה ועם מערך תוצאות גדול. סידור מחדש מופיע כתקיעות שתלויות בגודל, בעוד תקלת מאזין עוצרת את שני הגדלים באותה מידה.