האם לקוח L2TP השני הורג את הראשון? קראו את העטיפה
VPN אחד שעובד הופך לאפס כשמחשב נייד שני מתחבר. בדקו את עטיפת ESP מול UDP, מיפוי יציאות NAT וזהות כפולה, לא את הפרוטוקול.
מחשב נייד אחד מחזיק מנהרה עובדת דרך נתב המשרד. מחשב נייד שני באותו חדר מתחבר, והראשון נופל. אם זה כל התסמין, שלוש סיבות שונות עדיין על השולחן, ואיזה תיקון חל תלוי בדברים שעוד לא מדדתם. הנתב המשותף רלוונטי, אבל הוא לא אשם אוטומטית, וגם לא הפרוטוקול.
שלוש סיבות שנראות זהות מהספה
המועמד הראשון הוא הטיפול של הנתב ב-IPsec. נתבים זולים לצרכן מפרסמים לעיתים קרובות מעבר ישיר ומיישמים אותו עבור לקוח אחד בכל פעם, מפני שהמנגנון עוקב אחר עמית אחד ואינו יכול להפריד בין שני מחשבים ניידים מאחורי אותה כתובת ציבורית. התסמין הוא בדיוק מה שהייתם מצפים לו: ההפעלה החדשה יותר מנצחת.
השנייה היא החשבון. שרתי VPN רבים מתירים הפעלה אחת לכל זהות ומנתקים את הישנה יותר כאשר אותם פרטי גישה מאומתים שוב, וזו החלטת מדיניות בשער שאין לה שום קשר לנתב שלכם. חפשו את ההודעה המפורשת הזו ביומן השרת לפני שאתם קונים חומרה.
השלישית היא תצורה שגויה פשוטה: שני פרופילים שמצביעים על אותה זהות, אחד מהם עם מפתח משותף מראש מיושן או תעודה שהשער כבר לא מקבל. זה בדרך כלל מופיע כחיבור שני כושל ולא כנפילה של הראשון, כך שצורת הכשל כבר אומרת לכם משהו.
מה L2TP/IPsec באמת שולח דרך הנתב
IKE פועל מעל UDP 500. נתיב הנתונים הוא ESP, שהוא פרוטוקול IP 50 ואינו נושא שום יציאת TCP או UDP. לכן לנתב שמבין רק יציאות אין במה להיאחז, וזו בדיוק הסיבה שמנגנון המעבר הישיר קיים.
עם מעבר NAT, ESP נעטף בתוך UDP 4500. כעת לנתב יש יציאת מקור למפות, וכל מחשב נייד מקבל תרגום משלו, כך שהשער יכול להבדיל בין שני זרמים. זה המנגנון שמאפשר בכלל כמה לקוחות מאחורי כתובת אחת.
ההבחנה חשובה כשקוראים את רשימת התכונות של נתב. תווית שאומרת מעבר ישיר IPsec אומרת לכם שליצרן יש איזה מנגנון; היא לא אומרת אם המנגנון תומך בכמה לקוחות או איך הוא מתנהג כשמגיע השני.
התיעוד של strongSwan על מעבר NAT מתאר את העטיפה עצמה, וזה החלק שאפשר לאמת מתוך לכידות מנות ולא מעמוד שיווק.
איך לדעת איזו סיבה באמת יש לכם
בצעו ארבע תצפיות ורשמו כל תוצאה. כל מחשב נייד לבד: האם זה עובד, ולכמה זמן? שניהם יחד: איזה שורד? המחשב השני בנקודת גישה של טלפון: האם הראשון נשאר? ובשער: האם יומן השרת מראה הפעלה חדשה שמחליפה ישנה, או שהוא מראה לקוח אחד שפשוט משתתק?
התשובות האלה מפרידות את המועמדים בצורה נקייה. הודעת החלפה ביומן השרת מצביעה על מדיניות זהות. לקוח שמפסיק לקבל תעבורה בזמן שהנתב מציג תרגום חדש מצביע על הנתב. שני לקוחות ששניהם לא משלימים IKE מצביעים על תצורה או פרטי גישה.
שמרו על אותם פרופילים לאורך כל הדרך. החלפת פרופיל בין בדיקות פירושה שאתם מודדים שני משתנים בבת אחת, והמסקנה תהיה שגויה בדרך שקשה מאוד להבחין בה.
לכדו בנתב אם הוא תומך בכך, או במחשב נייד אחד בזמן שהשני מתחבר. לראות את המנות של הלקוח השני מופיעות בזמן שאלה של הראשון נפסקות הוא הוכחה חזקה יותר מכל סמל מחובר.
אם הנתב הוא המגבלה
השתמשו בתצורת ריבוי לקוחות המתועדת של היצרן אם היא קיימת, או החליפו את ההתקן באחד שהתיעוד שלו אומר את מה שאתם צריכים. זו תשובה לא זוהרת והיא היחידה ששורדת עדכון קושחה.
מה שלא עובד הוא להוסיף שני העברות נכנסות זהות לשני מחשבים ניידים שונים. העברה אומרת לנתב לאן לשלוח תעבורה נכנסת; היא לא אומרת לו לאיזה משני זרמים פעילים שייכת מנה, והעמימות היא הבאג.
אם אי אפשר להחליף את הנתב, שימו לקוח אחד מאחורי נתיב אחר. נקודת גישה של טלפון היא פתרון קבוע גרוע ופתרון אבחון טוב לגמרי.
אם השער הוא המגבלה
ספקו זהויות נפרדות לאנשים נפרדים. חשבון משותף אחד שמשתמשים בו שני מחשבים ניידים הוא הסידור שיוצר את התסמין הזה בשרתים שמוגדרים להפעלה אחת, ושום תצורה מקומית לא מתקנת החלטה שמתקבלת בקצה השני.
שאלו את בעל השער איזו מדיניות חלה: הפעלה אחת לכל חשבון, אחת לכל תעודה, או בלי הגבלה בכלל. התשובה שלהם קובעת אם אתם צריכים פרטי גישה חדשים או נתב חדש.
האימות הוא החלק שאנשים מדלגים עליו. הריצו תעבורה שימושית משני הלקוחות זמן רב יותר מהמרווח שנכשל קודם, מפני ששתי כניסות מוצלחות מוכיחות רק שהאימות עבד פעם אחת בכל אחת.