הוסיפו VPN אתרי לצד ראוטר הספק בלי לנתק שיחות

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

רשמו את התפקידים שכבר עובדים

תעדו את שער ברירת המחדל, שרת ה-DHCP, הפותר וההתקן שמחזיק את רישום הקול של הספק. בדוגמה הזו ראוטר הספק הוא 10.50.0.1, השער החדש יהיה 10.50.0.2 והאתר המרוחק הוא 10.60.0.0/24. שום דבר בתוכנית הזו לא משנה את שלושת התפקידים הראשונים, וזו בדיוק הנקודה. אחר כך ודאו שהקופסה השנייה באמת יכולה לסיים את המנהרה: בדקו את הפרוטוקול, את התפוקה הצפויה ואם היא מקבלת עדכוני קושחה או חבילות. התקן עם לוגו VPN ובלי מסלול עדכון הוא עול, לא תוספת.

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

תנו לשער החדש כתובת אחת ומשימה אחת

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

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

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

בחרו מי הבעלים של נתיב הקידומת המרוחקת

אפשרות A היא ראוטר הספק: הוא מחזיק נתיב סטטי ל-10.60.0.0/24 אל השער, וכל מארח עוקב אחרי שער ברירת המחדל שלו כמו קודם. אפשרות B היא לפי מארח: רק המכונות שזקוקות לאתר המרוחק מקבלות נתיב מפורש דרך 10.50.0.2, וכל השאר נשאר בלי שינוי. A נקייה יותר כשמארחים רבים, אבל בדרך כלל דורשת שראוטר הספק יקבל נתיב סטטי, ויש כאלה שלא. B לא דורשת שיתוף פעולה של הספק אבל משאירה לכם את תחזוקת תצורת המארחים, ולכן מתאימה לקבוצה קטנה ומאושרת של מכונות.

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

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

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

סדרו נקודת כניסה נגישה

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

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

קבלו את השירות הפרטי ואת קו הקול יחד

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

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

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