Listen, Bind ו-BindSame ב-Tinyproxy: איזו כתובת מנצחת
Listen בוחר את הכתובת שמקבלת לקוחות, Bind בוחר את המקור לחיבורים יוצאים. אף אחד מהם לא מתקין נתיב, לכן בדקו את המסלול בנפרד.
ה-proxy עונה, הבקשה מושלמת, ובכל זאת היעד עדיין רושם את כתובת ה-LAN. שום דבר ביומן ה-proxy לא נראה שגוי, והשורה ששיניתם היא בדיוק זו שהתיעוד אמר לכם לשנות. במארח שיש לו גם כתובת LAN וגם כתובת מנהרה, שלוש הנחיות קובעות איזו כתובת מופיעה היכן, ורק אחת מהן נוגעת לצד היוצא. קריאה בסדר שגוי תשלח אתכם לטבלת הניתוב בלי סיבה.
התסמין: היעד רואה את כתובת ה-LAN
לקוח מתחבר ל-proxy בכתובת ה-LAN, וה-proxy פותח חיבור משל עצמו ליעד. אותו חיבור שני בוחר כתובת מקור לפי כללי הליבה, וברירת המחדל היא מה שתבחר חיפוש הנתיב. לכן היעד רושם את הכתובת הראשית של המארח אף שכל בייט עבר דרך ה-proxy. מבחינת העברה שום דבר לא שבור, ולכן אין ליומן ה-proxy מה לומר על כך.
התמונה ההפוכה של התקלה הזו קלה יותר לזיהוי: נעצו את המקור היוצא בכתובת המנהרה ולקוחות ה-LAN מפסיקים להגיע למאזין לגמרי. אותה גרסה מכריזה על עצמה, בעוד הראשונה מתחבאת מאחורי בקשה שעובדת. שתיהן נובעות מלהתייחס להנחיה אחת כאילו היא עונה על שתי השאלות.
שלוש הנחיות, שלוש כתובות שונות
Listen נוקב בשם הכתובת המקומית שמקבלת את לקוחות ה-proxy. Bind מספק כתובת מקור לחיבורים שה-proxy יוצר החוצה, ו-BindSame מורה לו לעשות שימוש חוזר בכתובת המקומית של החיבור שהוא עתה קיבל. אלו שלוש שאלות נפרדות, ושורה אחת עונה רק על אחת מהן. ערבוב ביניהן הוא הסיבה השכיחה לכך ששינוי נראה כאילו אינו עושה דבר.
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The route, not the proxy: the source cannot reach that destination |
קראו את התצורה המתוירת שמגיעה עם הגרסה המותקנת, כי ברירות מחדל ותחביר מתקבל משתנים בין מהדורות. תצורת הדוגמה של הפרויקט מתעדת כל הנחיה לצד האחרות. השוו את הקובץ הזה לזה שעל הדיסק, ולא למדריך שנכתב להפצה אחרת.
הגדירו את המאזין ואת המקור היוצא בנפרד
קחו מארח שכתובת ה-LAN שלו היא 192.168.50.10 וכתובת המנהרה שלו היא 10.90.0.3. אם לקוחות ה-LAN צריכים להגיע ל-proxy ובמקביל בקשותיהם לצאת מהמנהרה, אלו שתי החלטות נפרדות ושתיהן חייבות להיכתב. הקטע שלהלן מבטא בדיוק את זה ושום דבר אחר.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noזו אינה תצורה מלאה, לכן שמרו על הפורט המאושר, האימות, בקרות הגישה של הלקוחות והגבלות היעד. שתי הכתובות חייבות להשתייך למארח הזה בתוך מרחב השמות של הרשת של Tinyproxy, כי ערך Bind שהתהליך אינו יכול להחזיק בו נכשל בזמן החיבור ולא בזמן האתחול. BindSame yes מתאר מדיניות אחרת, שבה הכתובת המקומית של החיבור שהתקבל הופכת למקור היוצא. במהדורות הנוכחיות לענף הזה יש עדיפות על פני רשימת Bind, וכך מקור מוגדר נעלם בלי שגיאה.
בדקו את הנתיב שהמקור מרמז עליו
בחירת כתובת מקור אינה יוצרת מסלול, לכן שאלו את הליבה מה הייתה עושה עם אותו מקור ואותו יעד. חיפוש שמציין את ממשק המנהרה הוא ההוכחה המזערית, וזה שמציין את ממשק ה-LAN פירושו שהמקור אינו יכול לעבוד כפי שנכתב. החיפוש הוא תלוי-הקשר: הוא מעריך את כללי המדיניות ואת הטבלה התקפים באותו מרחב שמות. זה אינו חיבור, והוא אינו אומר דבר על מה ש-NAT במורד יציג לשירות.
ip -4 route get 203.0.113.25 from 10.90.0.3השתמשו בכתובת תיעוד בדוגמה והחליפו אותה בשירות שאתם מורשים לבדוק. הריצו את החיפוש בתוך מרחב השמות של ה-proxy כשה-proxy פועל במכל, כי כללי המארח אינם הכללים שהתהליך רואה. כשאין את נתיב המנהרה המיועד, תנו לבעל הרשת לתקן אותו במקום להוסיף כללים ספציפיים ליעד על מארח ה-proxy. אל תנקו נתיבי מארח ואל תשביתו נתיבים שנדחפים מהשרת כדי שחיפוש יצליח, גם אם מדריך ישן עשה כך, כי שינויים כאלה מזיזים את כל התנהגות ה-VPN המאושרת של המארח כדי לתקן מסלול proxy אחד.
אמתו את המקור ביעד
קראו את המקור במקום שבו הבקשה מגיעה, ולא במקום שממנו היא יוצאת. יומן היישום של היעד, או התקן הקצה שלפניו, רושם את הכתובת שהוא באמת ראה, בעוד ה-proxy יכול לספר לכם רק מה הייתה כוונתו. שלחו בקשה חדשה אחת דרך המאזין המיועד לאחר השינוי, כי חיבור שנשמר במטמון אינו מוכיח דבר על הקישור החדש. אחר כך השוו את הכתובת שנרשמה לזו שהגדרתם.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl הוא רק מחולל התעבורה; הכתובת שראויה לאימות היא זו שהצד המרוחק רשם, ולא העמית שאליו curl התחבר במקרה. אם השניים אינם מסכימים, קבעו אם ההבדל נובע מבחירת המקור או מתרגום בהמשך הדרך, כי אלו מתוקנים במקומות שונים. תכננו יחד גם שינויי כתובות והפעלות מחדש של ה-proxy, כי קשירת כתובת שהמנהרה אינה מחזיקה בה עוד נכשלת בשקט לאחר התחברות מחדש. הגדירו בנפרד גם את התנהגות DNS ו-IPv6, כי קטע ה-IPv4 למעלה אינו מוכיח דבר על אף אחד מהם.