לקוחות VPN מתחברים אבל אין אינטרנט: שלושה חלקים חסרים

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

למה מנהרה עובדת עדיין בלי דרך החוצה

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

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

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

העברה היא מתג בליבה שחייבים להפוך לקבוע

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

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

הפכו אותו לקבוע בקובץ תחת /etc/sysctl.d/, ואז החילו את הקובץ הזה במקום לאתחל כדי לגלות. ב־FreeBSD המקבילה היא net.inet.ip.forwarding, עם gateway_enable=YES ב־rc.conf לקביעות. מכשיר שמדווח שההעברה מושבתת מסביר סוג שלם של דיווחים „חבילות מגיעות ושום דבר לא חוזר”. בדקו את ההגדרה גם אחרי כל שדרוג, כי ליבה שנבנתה מחדש או תמונת מכשיר שהוחלפה יכולות לאפס אותה בלי לספר לאיש.

בחרו masquerade או כתובת תרגום קבועה אחת

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

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

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

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

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

טבלת הסינון היא השער השלישי

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

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

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

היכן להסתכל כשדף לעולם לא נטען

עשו ping לכתובת המנהרה של השרת כדי להוכיח שהמנהרה קיימת. אחר כך הריצו traceroute מהלקוח לכתובת ציבורית וקראו היכן הוא נעצר: בשרת החבילה מגיעה אבל אינה מועברת או מתורגמת; מעבר לשרת הבעיה במעלה הזרם ומחוץ לידיים שלכם.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

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

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

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