לחיצת היד של PiVPN עובדת, העמודים נתקעים: בדקו את MASQUERADE

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

התחילו ממה שהלקוח יכול להגיע אליו ומה שלא

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

כתובת מנהרה שמגיבה ל-ping בזמן שאתרים ציבוריים מגיעים לפסק זמן היא הסימן לבעיית העברה או תרגום, לא ללחיצת יד שבורה. לוח המצב של הלקוח עצמו לא יכול להבחין ביניהם, כי הוא יודע רק שערוץ הבקרה פעיל. בדקו בשרת את ממשק המנהרה עם ip -br addr show tun0 ואשרו שהכתובת שהוקצתה ללקוח נופלת בתוך המאגר שהגדרתם. אם המאגר וכתובת הלקוח לא תואמים, תקנו את זה קודם, כי כל כלל בהמשך מתאים למאגר.

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

קראו את הכלל שקובע אם החבילות יוצאות

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

הציגו את הטבלה החיה וקראו את עמודת ממשק היציאה במקום רק לחפש את המילה MASQUERADE. קל יותר להשוות את הפלט בצורת ההוספה מאשר רשימה מעוצבת:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

על Raspberry Pi שהשתמש פעם ב-Ethernet וכעת משתמש ב-Wi-Fi, השם המיושן הוא כמעט תמיד כל הסיפור. המתקין תיעד איזה התקן היה נוכח בזמן ההתקנה, וקבוצת הכללים השמורה משחזרת אותו בכל אתחול. השוו את ההתקן מחיפוש המסלול לזה שבכלל לפני שאתם משנים משהו אחר. אם הם תואמים, הממשק אינו הבעיה שלכם וכדאי לעבור למונים בחלק האחרון. אם הם שונים, התיקון הוא עריכה של מילה אחת בקובץ ההתמדה.

תקנו את קבוצת הכללים השמורה, לא רק את זו שרצה

עריכה של הטבלה החיה בלבד מחזיקה עד האתחול הבא, וזה בדיוק מספיק זמן כדי לשכנע אתכם שהבעיה נפתרה. הכללים שחוזרים באתחול חיים בקובץ שחבילת התמדה של חומת האש טוענת מחדש. בתמונות Pi מבוססות Debian הקובץ הזה הוא בדרך כלל /etc/iptables/rules.v4.

קחו עותק לפני שנוגעים בו, ואז החליפו את ממשק היציאה בשורת MASQUERADE בהתקן שרשמתם, למשל -o wlan0 במקום -o eth0. השאירו את טווח המקור כפי שהוא, אלא אם מאגר הלקוחות שלכם השתנה. טענו מחדש ואשרו שהכלל מציין כעת את ההתקן הנכון:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

שתי הגדרות סמוכות קל לשכוח. sysctl net.ipv4.ip_forward חייב לדווח 1, והנתב העליון לא אמור לסנן בעצמו כתובות מקור פרטיות.

הוכיחו שהכלל פועל, ואז בודדו מה עדיין איטי

המונים הם ההוכחה הישרה היחידה לכך שכלל התאים. הריצו את הרשימה המפורטת, התחילו הורדה בלקוח והריצו שוב. עמודות החבילות והבתים ליד הכלל שלכם אמורות לעלות, וכלל שנשאר על אפס עדיין לא מתאים. אם המונים זזים אבל העמודים עדיין נכשלים, השוו את טווח המקור למאגר בפועל עם grep -n "^server " /etc/openvpn/server.conf. אם הם זזים והעמודים נטענים אבל התפוקה גרועה, התרגום הסתיים והבעיה הנותרת נמצאת במקום אחר.

השוו שתי העברות מאותו לקוח, אחת למארח ברשת המקומית ואחת דרך המנהרה לאותו מארח. איטיות בשני המקרים מצביעה על קישור היציאה של ה-Pi או על חיבור ה-Wi-Fi, לא על ה-VPN. איטיות רק דרך המנהרה מצביעה על MTU ועל שידורים חוזרים, שאפשר לבדוק עם ip -s link show tun0 לפני שמשנים הגדרת הצפנה כלשהי.

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