למה שירות ה-Linux הציבורי שלכם עונה דווקא דרך ה-VPN

שום דבר ב-socket לא זוכר איזה ממשק נשא את הבקשה, ולכן ברירת מחדל של VPN במנהרה מלאה יכולה ללכוד תשובה ששייכת ל-WAN. השירות אינו מתעלם מממשק הכניסה; Linux מנתב תשובה שנוצרה מקומית לפי היעד ומדיניות המקור. כלל מבוסס מקור יכול לשלוח רק את תשובות השירות דרך טבלת WAN מלאה, ולהשאיר את היציאה הרגילה במנהרה. הפורט נשאר פתוח בזמן שהתשובה יוצאת בנתיב הלא נכון, ולכן הסימפטום נראה חד-צדדי.

התפיסה השגויה: תשובות הולכות לפי הממשק שאליו הגיעו

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

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

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

מה הקרנל באמת מנתב: כתובת המקור

הידית שדרושה לכם היא הכתובת המקומית שהשירות משתמש בה לתשובות. במארח עם כתובת eth0 להמחשה 192.0.2.10/24 ושער 192.0.2.1, הכתובת הזו קיימת בממשק. ב-VM בענן הכתובת הציבורית עשויה להיות מתורגמת במעלה הזרם ולהיעדר מהאורח, ולכן השתמשו בכתובת שהמארח באמת מחזיק.

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

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

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

בנו טבלת חזרה מלאה, לא חצי ברירת מחדל

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

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

השתמשו בקידומת ובשער האמיתיים במקום להעתיק את הדוגמה. ממשק ענן שמוגדר בתצורת /32 עם שער על הקישור זקוק לנתיב מחובר אחר, וטבלה שנבנתה מהקידומת השגויה נכשלת בצעד הראשון. התכונה src מציינת את המקור המועדף לאותו נתיב; היא אינה מחליפה את כלל המקור.

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

אמתו בחיפוש מוגדר לפי מקור

בקשו מהקרנל לנתב יעד בדיקה מכתובת השירות. התשובה צריכה לנקוב ב-eth0 ובשער ה-WAN, לא במנהרה:

ip -4 route get 198.51.100.25 from 192.0.2.10

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

הניחו את הנתיבים הסופיים ואת הכלל תחת מנהל הרשת שמחזיק בממשק. שינויי כתובת, חידוש DHCP והתחברויות מחדש של VPN כולם כותבים מחדש את מצב הקרנל, וכלל שנוסף ביד נעלם או מצביע על שער מיושן לאחר האירוע הבא.

היכן החריג הזה נעצר

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

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

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

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