NAT כפול וה-VPN שלך: הלקוח עובד, השרת לא

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

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

שרטטו קודם את כיוון החיבור

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

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

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

יוצא: הלקוח שואל, המתרגמים ממפים

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

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

wg show
ping -c3 10.8.0.1

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

נכנס: העברה קדימה מכסה רק ציוד שבבעלותכם

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

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

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

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

בדקו משתנה אחד בכל פעם

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

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

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

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

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