כתובות IPv6 אינן מחליפות את ה-VPN שלכם: חזרו למשימה המקורית

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

תנו שם למשימה לפני שמסירים את הכלי

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

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

כתובת ציבורית אינה הצפנה

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

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

מה שהשכבה העליונה עדיין מספקת

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

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

עברו על השירות שהופך לציבורי

התחילו במארח ורשמו מה באמת מאזין, כי האפליקציה שאישרתם היא לעתים רחוקות הדבר היחיד במכונה. ss -lntup מדפיס כל מאזין TCP ו-UDP עם כתובת הכריכה שלו ומוסיף את התהליך הבעלים היכן שההרשאות שלכם מאפשרות זאת, מה שמראה במבט אחד אם ממשק ניהול יושב על כתובת כללית או רק על loopback. חזרו על זה כ-ss -6 -lntup אם המחסנית שלכם מחזיקה sockets של IPv6 בנפרד.

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

שני מבחנים, ואז החליטו מה לכבות

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

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