מנהרת VPN לא מתחברת לעולם: היכן החבילות באמת נעצרות

מנהרה שלעולם לא נוצרת משאירה יומן ריק בשני הקצוות. עקבו אחרי האם GRE, ESP או UDP 4500 נשמטים, ואתרו NAT של הספק לפני עריכת השרת.

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

הוכיחו היכן התעבורה נעצרת

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

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

PPTP מת בלי פרוטוקול 47

PPTP נושא בקרה על TCP 1723 ואת הנתונים שלו בתוך GRE, שהוא פרוטוקול 47 ב-IP ולא מספר פורט. העברת 1723 בלבד מפיקה את התוצאה הקלאסית: החיבור מאמת את עצמו ואז משתתק, כי אין כלל לפרוטוקול שנושא את המטען. הלקוח אינו יכול להבדיל בכך מסיסמה שנדחתה, ולכן הלכידה חייבת לבוא לפני שינויי התצורה.

מעבר ישיר פועל בכיוון ההפוך מהעברה נכנסת, וקושחה משתמשת לעיתים קרובות מספיק בתווית אחת לשתיהן כדי לבלבל את כולם. בלקוח לינוקס חומת האש המקומית יכולה להשליך GRE הרבה לפני שהנתב מעורב, ולכן פרוטוקול 47 זקוק לכלל משלו ויש לטעון את עוזר ה-conntrack. ufw של אובונטו שומר את הכללים האלה בקובץ before, כי כללי allow רגילים אינם יכולים לבטא מספר פרוטוקול. לאחר מכן טענו מחדש את חומת האש במקום לאתחל את המכונה.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP ו-IPsec מאחורי שני NAT

L2TP בתוך IPsec זקוק ל-UDP 500 עבור החלפת המפתחות, ל-UDP 4500 כאשר מזוהה NAT, ול-ESP כפרוטוקול 50. כל אחד מהם מסונן בנפרד, ולכן כלל שמתיר אחד אינו מוכיח דבר על השניים האחרים. שני נתבים בשרשרת מתרגמים כל חבילה פעמיים, והקצוות כבר אינם מסכימים על מה שנדון.

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

רשתות ספקים ושיתוף כתובות

כתובת WAN בתוך 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 או 100.64.0.0/10 פירושה שלנתב אין כתובת ציבורית ושום העברה נכנסת מהאינטרנט אינה יכולה להגיע אליו. NAT ברמת ספק גם מסנן פרוטוקולים שהוא אינו מצפה להם, ו-GRE הוא קורבן תדיר בקישורים סלולריים. השוו את כתובת ה-WAN בנתב עצמו, לא את הכתובת שאתר חיפוש מדווח ללקוח שמאחוריו.

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

קראו את רשימת המאזינים לפני שסוגרים פורטים

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

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

ברירות המחדל של SoftEther הן דוגמה טובה: TCP 443, 992 ו-5555, כאשר תכונות L2TP/IPsec ומנהרת DNS מוסיפות sockets משלהן. כיבוי התכונות האלה מסיר את המאזינים במקום להסתיר אותם, והבדיקה ממארח חיצוני אומרת לכם אם הספק בכלל מאפשר לפורט לעבור. מאזין שעונה מקומית יכול עדיין להיות סגור במעלה הזרם, ולכן השוו את כתובת ה-WAN של הנתב עצמו למה ששירות חיצוני מדווח.

מאמרים קשורים