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

הקצאה אינה הכרזה

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

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

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

מה נתיב הלקוח באמת לוכד

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

ip route get 198.51.100.20
ip -br addr show tun0
traceroute -n 198.51.100.20

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

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

השווה את המאגר לכל רשת שאתה מכיר

RFC 1918 מקצה שלושה בלוקים לשימוש פרטי: 192.168.0.0/16, 172.16.0.0/12 ו-10.0.0.0/8. מיליוני ארגונים נפרדים עושים בהם שימוש חוזר, ולכן «פרטי» הוא הצהרה על הקצאה ולעולם לא הבטחה שאיש אחר לא בחר באותם מספרים.

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

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

מתי כתובות ציבוריות הן התשובה הנכונה

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

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

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

הוצא מאגר גרוע משירות בלי לאבד גישה

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

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

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

מאמרים קשורים