שאלת ראיון F5: ה־Pool ירוק, ה־Virtual Server ירוק, ובכל זאת המשתמשים מקבלים Timeout. מה קורה?

אם יש שאלת F5 אחת שכמעט כל מראיין בצוותי תשתיות, בנקים וחברות אינטגרציה שואל, זו היא. היא נראית כמו שאלה על Load Balancing, אבל בפועל היא בודקת אם אתם מבינים איך חבילה עוברת דרך BIG-IP ואיך היא חוזרת. מי שמבין את זה פותר אותה בדקה. מי שלא, יתחיל לחפש בעיה בשרתים.

קודם כל, לקרוא נכון את הרמזים בשאלה

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

• ▸״כל ה־Pool Members ירוקים״: ה־Monitor מצליח לדבר עם השרתים. הבעיה לא בשרת שנפל ולא בפורט שגוי.
• ▸״הדף נטען בלי סוף ובסוף Timeout״: זה לא דחייה מיידית. דחייה מיידית הייתה מרמזת על פורט סגור או על הגדרת SSL שגויה מול השרת. המתנה ארוכה אומרת שחבילות נשלחות ותשובה לא חוזרת.
• ▸״כשאני ניגש ישירות לשרת, הוא עונה מיד״: האפליקציה תקינה. מה שנשבר זה המסלול דרך ה־F5.
• ▸״אפליקציה חדשה״: משהו הוגדר עכשיו, ולא נשבר אחרי שעבד. זה הזמן לחשוד בהגדרה שנשכחה, כמו Source Address Translation.

Full Proxy: שני חיבורים נפרדים, לא חיבור אחד

כדי להבין את הבעיה צריך להבין איך Standard Virtual Server עובד. ה־BIG-IP לא מעביר את החבילות של הלקוח הלאה כמו נתב. הוא מסיים את ה־TCP Handshake מול הלקוח, במקרה שלנו גם את ה־TLS ואת קבלת בקשת ה־HTTP, ורק אז פותח חיבור TCP חדש ונפרד לאחד השרתים ב־Pool. ב־F5 קוראים לזה Client-side ו־Server-side.

בצד השרת, ה־BIG-IP משנה תמיד את כתובת היעד: במקום כתובת ה־Virtual Server הוא שולח לכתובת של ה־Pool Member. את כתובת המקור הוא משנה רק אם הגדרתם Source Address Translation. בלי SNAT, השרת מקבל SYN שנראה כאילו הגיע ישר מהלקוח, למשל מ־198.51.100.25.

• ▸הלקוח 198.51.100.25 פותח חיבור ל־Virtual Server בכתובת 10.1.10.100:443, ומסיים מולו Handshake ו־TLS.
• ▸ה־BIG-IP בוחר Pool Member ושולח SYN מ־198.51.100.25 אל 10.1.20.11:80.
• ▸השרת רוצה לענות ל־198.51.100.25. זו לא כתובת ברשת שלו, אז הוא שולח את ה־SYN-ACK ל־Default Gateway, שהוא ה־Firewall בליבה ולא ה־F5.
• ▸ה־Firewall רואה SYN-ACK של חיבור שהוא לא ראה את תחילתו וזורק אותו כ־Out of State. אם אין Firewall בדרך והחבילה מגיעה ללקוח, הלקוח לא מכיר חיבור מול 10.1.20.11 ושולח RST.
• ▸ה־BIG-IP לא מקבל תשובה, שולח את ה־SYN שוב ושוב, ובסוף מוותר. המשתמש רואה דף שנטען עד שנגמר הזמן, או חיבור שמתאפס.

איך מוכיחים את זה על ה־BIG-IP

מראיין לא מסתפק ב״נראה לי שזה SNAT״. הוא רוצה לשמוע איך תוכיחו. הנה סדר עבודה מסודר, מהתמונה הכללית ועד החבילה הבודדת.

# סטטוס וסטטיסטיקות של ה-Virtual Server
tmsh show ltm virtual vs_app_https

# סטטוס ה-Pool Members
tmsh show ltm pool pool_web members

# האם יש Source Address Translation
tmsh list ltm virtual vs_app_https source-address-translation

# פלט בעייתי:
# ltm virtual vs_app_https {
#     source-address-translation {
#         type none
#     }
# }

tmsh show sys connection cs-client-addr 198.51.100.25

# דוגמה לפלט בלי SNAT:
# 198.51.100.25:51234  10.1.10.100:443  198.51.100.25:51234  10.1.20.11:80  tcp  9  (tmm: 1)
#
# עמודה 1: הלקוח        עמודה 2: ה-Virtual Server
# עמודה 3: מקור בצד השרת  עמודה 4: ה-Pool Member

# אותו חיבור עם SNAT Automap:
# 198.51.100.25:51234  10.1.10.100:443  10.1.20.250:51234  10.1.20.11:80  tcp  3  (tmm: 1)

# 0.0 = כל הממשקים, :nnn מוסיף מידע פנימי של TMM על כל חבילה
tcpdump -nni 0.0:nnn -s0 host 10.1.20.11 and port 80

# מה רואים כשיש ניתוב אסימטרי:
# 198.51.100.25.51234 > 10.1.20.11.80: Flags [S]
# 198.51.100.25.51234 > 10.1.20.11.80: Flags [S]   <- שידור חוזר
# 198.51.100.25.51234 > 10.1.20.11.80: Flags [S]   <- ועוד אחד
# ואין אף Flags [S.] שחוזר מהשרת

# כדי לשמור לקובץ ולפתוח ב-Wireshark:
tcpdump -nni 0.0:nnn -s0 -w /var/tmp/app_issue.pcap host 10.1.20.11 and port 80

# Linux
ip route get 198.51.100.25
# 198.51.100.25 via 10.1.20.1 dev eth0    <- ה-Firewall, לא ה-F5

# Windows
Get-NetRoute -DestinationPrefix 0.0.0.0/0
route print

הפתרונות, והמחיר של כל אחד

כאן אפשר להרשים. מועמד ממוצע אומר ״מדליקים SNAT Automap״. מועמד טוב מסביר שיש כמה דרכים, ומה כל אחת עולה.

• ▸SNAT Automap: ה־BIG-IP מחליף את כתובת המקור בכתובת Self IP שלו ב־VLAN שדרכו הוא יוצא לשרת, ומעדיף Floating Self IP אם יש. השרת עונה ל־F5, והמסלול סימטרי. זה הפתרון הנפוץ והמהיר. ב־HA הכתובת הצפה עוברת ליחידה הפעילה, ולכן Failover לא שובר את זה.
• ▸SNAT Pool: אותו רעיון, אבל עם כמה כתובות שאתם בוחרים. משתמשים בו כשיש הרבה חיבורים במקביל לאותו שרת. לכל כתובת SNAT יש בערך 64 אלף פורטים מול כל יעד, ובעומס גבוה אפשר להגיע ל־Port Exhaustion.
• ▸Routed Mode, בלי SNAT: מגדירים את ה־Floating Self IP של ה־F5 כ־Default Gateway של השרתים. כתובת הלקוח נשמרת עד השרת, וזה יתרון גדול לאפליקציות שצריכות אותה. המחיר: כל התעבורה היוצאת מהשרתים עוברת דרך ה־F5, כולל עדכונים וגיבויים, וצריך Forwarding Virtual Server בשבילה. בנוסף, לקוחות שנמצאים באותה רשת של השרתים עדיין יקבלו תשובה ישירה ויצטרכו SNAT.
• ▸nPath, או Direct Server Return: התשובה עוקפת את ה־F5 בכוונה. זה עיצוב שונה לגמרי, עם Loopback על השרתים ו־FastL4, ומאבדים יכולות כמו SSL Offloading. כדאי להזכיר שאתם מכירים, ולהבהיר שזה לא הפתרון לתקלה הזו.

# פתרון 1: SNAT Automap
tmsh modify ltm virtual vs_app_https source-address-translation { type automap }

# פתרון 2: SNAT Pool עם שתי כתובות
tmsh create ltm snatpool snatpool_app members add { 10.1.20.201 10.1.20.202 }
tmsh modify ltm virtual vs_app_https source-address-translation { type snat pool snatpool_app }

# לשמור את ההגדרה
tmsh save sys config

רגע, אז השרתים כבר לא רואים את כתובת הלקוח?

זו שאלת ההמשך שכמעט תמיד מגיעה. נכון, אחרי SNAT השרת רואה בלוגים את כתובת ה־F5 ולא את הלקוח. צוות האבטחה או צוות האפליקציה ירצו לדעת מי באמת גלש. כאן נכנס X-Forwarded-For.

מכיוון שה־Virtual Server מפענח את ה־TLS עם Client SSL Profile ויש לו HTTP Profile, ה־BIG-IP רואה את בקשת ה־HTTP ויכול להוסיף לה Header עם כתובת הלקוח המקורית. השרת צריך להגדרה קטנה כדי לרשום בלוג את ה־Header במקום את כתובת המקור.

# פרופיל HTTP חדש שיורש מברירת המחדל ומוסיף XFF
tmsh create ltm profile http http_xff defaults-from http insert-xforwarded-for enabled

# להחליף את פרופיל ה-HTTP של ה-Virtual Server
tmsh modify ltm virtual vs_app_https profiles delete { http } profiles add { http_xff }

# בשרת: nginx (ngx_http_realip_module)
# set_real_ip_from 10.1.20.0/24;
# real_ip_header X-Forwarded-For;

# בשרת: Apache (mod_remoteip)
# RemoteIPHeader X-Forwarded-For
# RemoteIPInternalProxy 10.1.20.0/24

תשובות שכדאי לא לתת

• ▸״השרתים איטיים, צריך להוסיף עוד Pool Members״: השאלה אמרה שגישה ישירה עונה מיד. מי שמתעלם מזה לא הקשיב.
• ▸״זו בעיית Persistence״: Persistence קובע לאיזה שרת חוזר משתמש. הוא לא גורם לכל החיבורים להיתקע כבר בפתיחה.
• ▸״להחליף את ה־Monitor״: ה־Monitor דווקא עובד נכון. הוא פשוט בודק משהו אחר ממה שחשבתם. אפשר לשפר אותו, אבל זה לא יפתור את התקלה.
• ▸״להפעיל Auto Last Hop״: Auto Last Hop דואג שהתשובה ללקוח תחזור דרך אותו נתב שממנו הגיעה הבקשה, כלומר הוא נוגע בצד הלקוח. הבעיה כאן בצד השרת, וברוב ההתקנות הוא כבר מופעל כברירת מחדל.
• ▸״להוסיף Route בשרתים לכל רשתות הלקוחות דרך ה־F5״: זה יכול לעבוד, אבל מועמד שמציע את זה כפתרון ראשון בלי להזכיר SNAT נשמע כמו מי שלא עבד עם F5 בייצור.

שאלות המשך שכדאי להיות מוכנים אליהן

• ▸מה ההבדל בין SNAT ל־NAT ב־BIG-IP? NAT הוא מיפוי אחד לאחד בשני הכיוונים, כתובת פנימית אחת מול כתובת חיצונית אחת. SNAT מתרגם רק את כתובת המקור של חיבורים יוצאים, והרבה מקורות יכולים לחלוק כתובת אחת.
• ▸מה ההבדל בין Self IP רגיל ל־Floating Self IP? Self IP רגיל שייך ליחידה אחת בזוג ה־HA, ומשמש למשל ל־Monitors. Floating Self IP עובר ליחידה הפעילה ב־Failover, ולכן הוא זה שמגדירים כ־Default Gateway של שרתים ושבו SNAT Automap מעדיף להשתמש.
• ▸מה ההבדל בין Standard Virtual Server ל־Performance (Layer 4)? Standard הוא Full Proxy עם שני חיבורי TCP נפרדים ותמיכה בפרופילים כמו HTTP ו־SSL. Performance (Layer 4) משתמש ב־FastL4 ומעביר חבילות בלי לפתוח חיבור נפרד. גם בו התשובה חייבת לחזור דרך ה־F5, אלא אם בניתם nPath בכוונה.
• ▸איך מזהים Port Exhaustion ב־SNAT? חיבורים חדשים נכשלים בעומס גבוה בזמן שהשרתים בריאים. בודקים את הסטטיסטיקות ב־tmsh show ltm snat-translation ואת הלוג ב־/var/log/ltm, ומוסיפים כתובות ל־SNAT Pool.
• ▸למה ב־Wireshark על השרת רואים את ה־SYN-ACK יוצא, וב־F5 לא רואים אותו? כי השרת שולח אותו ל־MAC של ה־Default Gateway. בודקים את כתובת ה־MAC של היעד בחבילה ומשווים אותה ל־MAC של ה־Floating Self IP.