שרת VPN ביתי אינו נגיש: עברו את שרשרת ה-NAT

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

התחילו בעמוד ה-WAN של הנתב

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

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

עלו קפיצה אחת כלפי מעלה

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

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

אמתו את המאזין ואת ההעברה

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

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

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

שנו את הטופולוגיה, לא את אותו כלל

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

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

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