נתיב VPN או כלל חומת אש: מה מפיל את החבילה?

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

שתי החלטות, חבילה אחת, שני בעלים

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

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

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

קראו מה החיפוש בחר בפועל

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

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

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

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

הסינון חל בקרס, לא בנתיב

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

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

שלחו בדיקה דרך המסלול שהלקוח משתמש בו

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

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

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

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

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

שימו כל שינוי במקום שבו הוא שורד התחברות מחדש

נתיב שנוסף עם ip route add חי עד שהממשק נופל. שמרו אותו בפרופיל החיבור במקום זאת: NetworkManager מקבל נתיבים נוספים על החיבור, ו-netplan שומר עליהם בין אתחולים. אותו כלל חל על חריגה בחומת האש בצד הלקוח, שנעלמת לאחר הטעינה מחדש הבאה.

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

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