לקוח ה-VPN השני שבר את הראשון: מצאו את המשאב המשותף

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

עברו על ארבע השכבות לפי הסדר

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

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

התחילו בשירות שמסרב לרוץ פעמיים

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

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

אחר כך שאלו למי שייך הפורט

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

Get-NetUDPEndpoint -LocalPort 500,4500 | Select-Object LocalAddress,LocalPort,OwningProcess
netstat -ano | findstr :500
sudo lsof -nP -iUDP:500
ss -lunp | grep -E ':500|:4500'

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

מנהל התקן הסינון יושב מתחת לנתיבים שלכם

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

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

החליטו איזה מוצר מחזיק באתחול, ואז רשמו זאת

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

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