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

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

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

התחל מהמאזין, לא מהמנהרה

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

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

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

ארבע בדיקות לפני שתערוך משהו

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

1. ודא שהמנהרה בשימוש היא הפרופיל שמסביבו נבנה ה-proxy, ולא פרופיל שני שהתחבר מעצמו.
2. הדפס את הכתובת שנמצאת כעת בהתקן הזה והשווה אותה לכתובת בתצורה שרצה.
3. שאל את המפנה איזה מקור הוא פתר, ולא מה שהקובץ בדיסק טוען.
4. ודא שהתעבורה מהמפנה כפופה באמת למדיניות הניתוב וחומת האש שאתה מצפה לה.

כתובת ההתקן קלה: ip -4 addr show dev tun0 מדפיס את הנוכחית, ו-ip -4 route get 1.1.1.1 מראה איזה ממשק הליבה הייתה בוחרת ליעד הזה. מפנה שנקשר לכתובת מדויקת נכשל בקול כשהכתובת נעלמת. מפנה שנקשר להתקן, או נופל חזרה למקור ברירת המחדל, ממשיך לעבוד ולדלוף, וזו התוצאה השקטה.

התאם את התיעוד למהדורה שאתה מריץ, לא לתוצאת החיפוש הראשונה. הנחיית כתובת היציאה של Squid מתועדת עבור v7 וגרסאות קודמות, והתיעוד של v8 אומר במפורש שהנחיה זו אינה זמינה שם, כך שסקריפט שנבנה סביבה לא שורד את הגבול הזה (ראו מדריך Squid tcp_outgoing_address). אמת עם המנתח של המוצר עצמו לפני שמשהו נטען מחדש: squid -k parse מדווח על שגיאות ויוצא בלי לגעת בתהליך שרץ.

מספר כל מנהרה וזרוק החלפות מיושנות

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

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

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

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

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

הוכח את היציאה החדשה בבקשה טרייה

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

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

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

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