איך לתכנן מאגר כתובות של לקוחות VPN שמתאים

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

התחילו בשדה המאגר, לפני שכל לקוח מתחבר

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

לאחר שיש לכם את השדה, רשמו את הטווחים שכבר קיימים: ה-LAN של המשרד, כל אתר מנותב, ה-VPC בענן וכל מאגר אחר שעדיין בשירות. החפיפה נקבעת באריתמטיקה של קידומת, לא לפי אם מספרי המארחים נראים מוכרים, ולכן השוו את המצרף לכל אחד מהטווחים האלה. שני טווחים שנראים כמו 10.x אינם מזיקים כשהמצרפים שלהם אינם נחתכים, ותקרית תמיכה כשהם נחתכים.

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

קראו את הכתובת שהלקוח קיבל בפועל

חברו לקוח אחד וקראו מה המנהרה מדווחת, לא מה המאגר הבטיח. הלקוח מציג את הכתובת הפנימית שלו במצב החיבור, וב-Linux הממשק נושא אותה ישירות.

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

ip -4 addr show tun0
ip route get 192.168.50.20

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

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

עקבו אחרי תשובה בחזרה מהשירות

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

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

שני לקוחות, ואז ביטול אחד

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

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

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

רשמו את ארבעת הערכים במקום שבו השינוי הבא ימצא אותם

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

שמרו לצידה את הערת הבעלות: טווח המנהרה שייך לשרת ה-VPN, ו-הזמנה שנעשתה בהיקף ה-DHCP של ה-LAN לא מזמינה דבר ללקוח בתוך המנהרה. השורה האחת הזו מונעת את העבודה החוזרת הנפוצה ביותר, שבה מישהו מוסיף הזמנה ומצפה שכתובת המנהרה תעקוב אחריה.