איך להגדיר ראוטר נסיעות מאחורי פורטל הכניסה של מלון
קודם אשרו את המקום, ואז התחילו את המנהרה. בדקו מצב לקוח, DNS ומה מקבל מכשיר במורד הזרם, במקום לסמוך על נורית המצב של הראוטר.
אתם פותחים את דף הניהול של ראוטר הנסיעות והפיתוי הוא להתחיל מיד את ה-VPN. לרשת המלון יש תוכניות אחרות: הראוטר שלכם הוא לקוח של ה-Wi-Fi של המקום, וכל עוד החיבור העליון הזה לא מאושר, שום מנהרה לא מגיעה לשום מקום. עברו את שני השלבים לפי הסדר, והראוטר יפסיק להיראות תקול.
קודם בדקו שהראוטר מסוגל לבצע את שתי המשימות
אתם צריכים מצב לקוח עליון, שנקרא בדרך כלל משחזר, לקוח או WISP, ולקוח VPN יוצא. אלה תכונות שונות משרת VPN, והרבה ראוטרים זולים כוללים את השנייה ולא את הראשונה.
בדף הניהול, מצאו את קטע WAN או האינטרנט והחליפו אותו למצב לקוח אלחוטי. סרקו אחר ה-SSID של המקום, הצטרפו אליו, ותנו לראוטר לקבל כתובת לפני שתגדירו משהו אחר.
אשרו את גרסת הקושחה בזמן שאתם שם. שמות התפריטים זזים בין גרסאות, וייתכן שנתיב של מדריך ישן כבר לא קיים למרות שהתכונה קיימת. רשמו את הדגם והגרסה עם ציוד הנסיעה שלכם. כששלב מתועד לא תואם למסך שלפניכם, הפרש הגרסאות הוא כמעט תמיד הסיבה.
שנית, אשרו את החיבור העליון
חברו מחשב נייד לראוטר ופתחו כל דף HTTP. הפורטל אמור להפנות מחדש, ומשם חל הנוהל של המקום עצמו. חלק מהפורטלים עובדים טוב יותר מטלפון מאשר מראוטר בלי מסך, ולכן לעשות זאת ממכשיר מחובר הוא בדרך כלל מהיר יותר.
חסימת VPN קפדנית יכולה לסבך את האתחול הזה. אם המקום משליך את תעבורת המנהרה לפני אישור, לקוח ה-VPN בראוטר ייכשל כל עוד הפורטל ממתין, וכשל כזה הוא צפוי ולא תצורה שגויה.
השתמשו בשיטה נתמכת כדי לעבור את זה. הסרת כמה בקרות בבת אחת, או התקנת תעודה שדף פורטל מציע כתיקון, מחליפה אי נוחות זמנית בבעיה קבועה.
שלישית, התחילו את ה-VPN עם פרופיל שהוא תומך בו
כשהגישה הרגילה עובדת, התחילו את לקוח ה-VPN של הראוטר עם הפרופיל שהוא באמת תומך בו. תצורת WireGuard ופרופיל OpenVPN אינם ניתנים להחלפה, ואף אחד מהם לא ניתן לייבוא לשדה IPsec מקורי.
בדקו שלושה דברים לפני שאתם סומכים עליו: נקודת הקצה נגישה, הפותר עונה בערך הצפוי, וכתובת היציאה היא זו שאתם מצפים לה. בדיקת היציאה היא היחידה שמוכיחה שהמנהרה נושאת תעבורה ולא רק מוגדרת.
curl -sS https://ifconfig.me
cat /etc/resolv.confאם הראוטר מדווח על חיבור וכתובת היציאה היא עדיין של המקום, המנהרה לא נושאת את התעבורה שאתם חושבים. תקנו את זה לפני שתוסיפו מכשירים במורד הזרם לתמונה.
רביעית, בדקו ממכשיר במורד הזרם
דף המצב של הראוטר מתאר את החיבור של הראוטר עצמו. שלחו בקשה חדשה מהמחשב הנייד שאמור להיות מכוסה, ובדקו בנפרד IPv4, IPv6 ואת הפותר, כי מכשיר יכול להיות מכוסה למשפחה אחת ולא לאחרת.
| Stage | What to verify | Where |
|---|---|---|
| Upstream join | Router has an address from the venue | Router WAN status |
| Portal authorization | A fresh request loads a public page | Connected laptop |
| Tunnel | Egress address changed | Router or laptop |
| Downstream coverage | Laptop resolves and reaches the private resource | Laptop |
אם המחשב הנייד נכשל בעוד הראוטר מצליח, הבעיה בנתיב במורד הזרם: NAT, DHCP או מדיניות מנהרה שמכסה רק את התעבורה של הראוטר עצמו. בדקו שלמחשב הנייד יש כתובת מהמאגר של הראוטר, ואז ששער ברירת המחדל שלו הוא הראוטר. מכשיר שעדיין מחזיק חכירה משרת ה-DHCP של המקום נמצא ברשת שגויה לחלוטין.
חמישית, החליטו על החלופה ושמרו על הכניסה
בדקו מה קורה כשהפורטל פג או כשהמנהרה נופלת. המדיניות שבחרתם חייבת לכסות תעבורה מועברת, לא רק בקשות שהראוטר עצמו שולח, אחרת מכשיר במורד הזרם יחזור בשקט לחיבור של המקום.
שמרו את תהליך הכניסה העליון המאומת יחד עם הראוטר, על נייר או בהערה מקומית. הפעלה מחדש במלון הבא הופכת למשימה של שתי דקות במקום תצורה מאולתרת נוספת. שמרו עותק גם מחוץ לראוטר, כי הערה שנשמרת רק במכשיר אינה זמינה בדיוק כשהמכשיר הוא זה שנכשל. הנייר עדיין מנצח במקרה הזה.
ואז רשמו את ארבעת הערכים שהפעילו את זה: מצב עליון, נוהל הפורטל, סוג פרופיל VPN ובדיקת היציאה. ארבעת אלה הם מה שתצטרכו בפעם הבאה, והם הארבעה שהכי קשה לשחזר מהזיכרון.