התאימו את לקוח ה-VPN של לינוקס לפרוטוקול של המכשיר הישן

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

תעדו מה הצד הרחוק מפרסם

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

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

PPTP: הוכיחו GRE לפני שעורכים את pppd

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

pppd call branch-office
tcpdump -ni any proto gre -c 5

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

L2TP/IPsec: הצעה אחת תואמת מנצחת עשרה ניסיונות

קראו את יומן הדמון ולא את תיבת הדו-שיח של שולחן העבודה, כי התיבה ממזגת כמה כשלים נפרדים להודעה אחת. שגיאת NO_PROPOSAL_CHOSEN שייכת לשלב הראשון: הלקוח הציע הצפנה, גיבוב או קבוצת Diffie-Hellman שהשרת לא יקבל. פרטו מה המכשיר תומך וכתבו הצעה אחת שתואמת לכך, כי שילובים אקראיים בדרך כלל מייצרים את אותה שגיאה לאט יותר. בשולחן עבודה הלקוח המעשי הוא תוסף NetworkManager L2TP עם strongSwan או Libreswan מתחתיו.

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

IKEv1 אגרסיבי עם XAuth, ומקרה הפורטל

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

conn branch
    keyexchange=ikev1
    aggressive=yes
    leftauth=psk
    leftauth2=xauth
    leftsourceip=%config
    right=203.0.113.10

גרסאות strongSwan ישנות השתמשו ב-xauth=client במקום שבו גרסה 5 משתמשת ב-leftauth2=xauth, כך שקטע מועתק עלול להיכשל רק בגלל התחביר. בפורטל TLS, openconnect שמדבר בפרוטוקול AnyConnect מטפל ב-Cisco וברוב המותגים הממותגים מחדש, והוא זקוק להתקן TUN ולהרשאות להגדירו. העבירו את כתובת הפורטל בדיוק כפי שהדפדפן מציג אותה, כולל כל נתיב שהמכשיר מצפה לו, ואז בדקו את הכתובת שהוקצתה לפני שתבדקו משהו מאחוריה. יצירת הממשק מראש מסירה סוג אחד של הפתעה בזמן ההגדרה.

sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com

התחברו, ואז אמתו בסדר קבוע

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

ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal

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