שני אתרים סלולריים בלי פורטים נכנסים: לבנות רכזת שעובדת

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

לא ניתן לחייג לאף אחד מהאתרים, ולכן שניהם חייבים לחייג החוצה

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

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

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

ip -4 addr show scope global
ip -6 addr show scope global

מי מציג עמיתים, ומי נושא את החבילות

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

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

מסלול אחד לכל אתר, בבעלות עמית

הרכזת צריכה מנהרה אחת לכל אתר, קידומת LAN נפרדת מאחורי כל אחת ומסלול לכל קידומת שמציין את הבעלים שלה. בדוגמה הרכזת היא 10.61.0.1, אתר A הוא 10.61.0.11 עם LAN 10.60.10.0/24, ואתר B הוא 10.61.0.12 עם LAN 10.60.20.0/24. כל מסלול למטה מצביע על העמית שמחזיק בקידומת ולא על ממשק המנהרה:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

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

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

שמור כל מיפוי חי דרך הספק

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

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

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

הוכח את שני הכיוונים, ואז הוכח התאוששות

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

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

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