NO_PROPOSAL_CHOSEN ב-L2TP? סרוק קודם את השער

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

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

מה ההודעה שוללת

הדחייה מתרחשת במצב ראשי, לפני כל חילופי L2TP או PPP, ולכן המנהרה ומסד נתוני המשתמשים לא נבדקו. שלב 1 מנהל משא ומתן על הצפנה, על שלמות ועל קבוצת Diffie-Hellman. שלב 2 מנהל משא ומתן על הצעת ESP עבור הנתונים. כשל בשלב 1 אינו מתוקן על ידי שינוי הגדרת PFS בשלב 2, וקישור IKE שהושלם אינו מוכיח שהצעת ESP מתאימה.

רשום את ה-backend לפני עריכת התחביר: ipsec --version. libreswan ו-strongSwan מקבלים איותים שונים של ההצעה עבור אותם אלגוריתמים.

לאחר מכן קרא את הדחייה בהקשר עם journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

סרוק את השער כדי לגלות את מערך התמורות שלו

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

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

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

התאם את החפיפה בלי לכבות את האבטחה

הזן רק את התמורות שמופיעות גם בסריקה וגם במדיניות שלך. הדוגמה שלהלן משקפת שער שמציע 3DES, SHA1 ו-MODP1024 בשלב 1. שים לב להסתייגות לגבי ה-backend: libreswan 4.x אינו מהדר את קבוצת modp1024, ולכן זה חל על strongSwan או על בנייה של libreswan עם תמיכת DH2. אמת את הגרסה לפני שתסיק שהלקוח שבור.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

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

בדוק את הדמון ואת הפורט לפני ניסיון חוזר

NetworkManager-l2tp מפעיל מופע xl2tpd משלו. אם שירות המערכת כבר מחזיק ב-UDP 1701, הלקוח נופל חזרה לפורט מקור אפמרי, מה ש-RFC 3193 מתיר וחלק מהשרתים מפילים בשקט. בדוק את בעל ה-socket לפני הניסיון הבא.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

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

לבסוף, בדוק מהיכן הגיעה העצה. ipsec.conf שנכתב עבור IKEv1 XAuth מתאר סוג אחר של VPN, וההצעה שלו אינה השורה היחידה שתהיה שגויה בפרופיל L2TP. רשום את מערך התמורות שהזנת לצד הפרופיל, כדי שהאדם הבא לא יחזור על הבדיקה.

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