GVC נתקע ב־Acquiring IP: זו אינה בעיית סיסמה

Global VPN Client עומד על Acquiring IP, והתגובה הראשונה היא להקליד שוב את הסיסמה או להתקין מחדש את הלקוח. אף אחד מהם לא נוגע בשלב שנכשל. האימות הסתיים לפני שהלקוח ביקש כתובת בכלל, ולכן פרטי ההתחברות אינם מה שמחזיק אתכם בשורה הזאת. מה שמחזיק אתכם שם הוא חילוף DHCP שלא הסתיים, והוא יכול להיתקע בשלושה מקומות שונים.

אימות והקצאת כתובת הם שלבים נפרדים

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

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

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

מאין מגיעה החכירה באמת

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

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

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

מנהרה יכולה להיות פעילה ובכל זאת לאבד את החכירה

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

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

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

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

התחילו במתאם והתקדמו החוצה, כך שכל שלב יכול להיכשל רק מסיבה אחת:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

כתובת כמו 169.254.x.x פירושה שהמתאם קיים ולא קיבל שום תשובה, מה שמצביע על מקור החכירה או על נתיב הנתונים. כתובת נכונה בטווח ה־VPN עם רשומות DNS שגויות היא תקלה אחרת: החכירה עבדה והמדיניות סיפקה הגדרות חלקיות. מתאם שלעולם אינו מופיע פירושו שהלקוח לא הגיע ליצור אותו.

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

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