האם לקוח VPN נווד יכול לארח שירות עבור המשרד?

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

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

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

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

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

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

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

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

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

שמות וכתובות הם החלטות תכנון

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

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

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

בחנו את השירות, לא את החברות

מהיעד, אשרו מה מאזין ובאיזו כתובת, ואחר כך אשרו את תצוגת השער של נתיב החזרה:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

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

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

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