איזו כתובת מקור ירשום NGINX עבור לקוח VPN?
החליטו מה NGINX רואה לצד OpenVPN על מארח אחד: כתובת מנהרה פנימית, כתובת יציאה ציבורית או עמית מועבר, בהתאם למסלול שנבחר.
שלוש כתובות לקוח מופיעות בהתקנת NGINX ו-OpenVPN על אותו מארח, אחת לכל מסלול שבקשה יכולה לבחור. דפדפן שמגיע לכתובת המנהרה, דפדפן שמגיע לכתובת הציבורית ותוכנית שיוצאת דרך נתיב האינטרנט של השער נראים שונים זה מזה בשקע המאזין. החליטו איזה מסלול אתם רואים לפני שאתם מפרשים את שורת היומן. ההחלטה תלויה ביעד שהלקוח השתמש בו, בחריגה שהוא מחזיק עבור נקודת הקצה החיצונית של ה-VPN ובשאלה אם משהו מתרגם את החבילה בדרך.
החליטו לפי יעד, לא לפי מי המשתמש
התחילו בכתובת שאליה נשלחה הבקשה, מפני שכתובת זו בוחרת את המסלול. בקשה לכתובת המנהרה של המארח מגיעה בממשק המנהרה כשכתובתו הפנימית של הלקוח היא המקור. בקשה לכתובת הציבורית של המארח מגיעה בדרך כלל בממשק הפונה לאינטרנט עם הכתובת הציבורית של הלקוח, גם כאשר באותו מחשב נייד יש מנהרה פעילה באותו רגע. לכן חברות במאגר ה-VPN היא תכונה של מסלול החבילה, ולא תכונה שעוקבת אחרי המשתמש.
| Path the request took | Source the site normally records |
|---|---|
| Client reaches the site at its tunnel address, 10.24.0.1 | Client inner address, 10.24.0.20 |
| Client reaches another internet site through the gateway | Gateway public egress address, 192.0.2.44 |
| Client reaches the gateway's public address through the endpoint exception | Client's own public access address |
דווקא השורה השלישית הזו היא הראשונה שכדאי לבדוק כאשר משתמש VPN מופיע ביומן עם כתובת שאין לה דבר עם המנהרה. היא גם מסבירה מדוע שני משתמשים באותו פרופיל יכולים ליצור רשומות שונות: רשתות הגישה שלהם שונות, וכלום במנהרה לא כותב על זה מחדש.
מדוע נקודת הקצה החיצונית יוצרת מסלול ציבורי שני
הלקוח חייב להגיע לכתובת הציבורית של השער כדי להקים את המנהרה, ולכן מסלול לכתובת הזו חייב להתקיים מחוץ למנהרה. כאשר לקוח מפנה את כל התעבורה פנימה, מימוש סביר מחזיק מסלול מארח מפורש לכתובת הציבורית של השרת כדי להימנע ממנהרה שתלויה בעצמה. החריגה הזו אינה בררנית לגבי שירותים, ולכן כל בקשה לאותה כתובת ציבורית הולכת אחריה, כולל בקשת דפדפן לאתר המתארח בשער.
זהו המנגנון שמאחורי רוב הדיווחים המבלבלים בתחום הזה, והוא תלוי במימוש הלקוח ולא בשרת. לכן שני לקוחות עם פרופילים זהים יכולים להתנהג אחרת. הסרת החריגה כדי »לתקן« את היומן מפילה גם את המנהרה, ולכן החזיקו בה ותכננו סביבה.
קראו את השקע, הטבלה ופורמט היומן יחד
שלוש תצפיות קובעות איזה מסלול אתם רואים: היכן השקע מאזין, איזה ממשק עונה ליעד ומה פורמט היומן באמת רושם. אם המאזין קשור רק לכתובת המנהרה, בקשה ציבורית לא יכולה להגיע אליו כלל, מה שפוסל שתי שורות מיד. אם החיפוש עבור הלקוח מחזיר את התקן המנהרה, הבקשה הגיעה עם מקור פנימי והיומן אמור להראות זאת.
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44לאחר מכן קראו את הפורמט ולא את השורה. שדה שמזין כותרת מועברת רושם טענה, לא עמית שקע, והטענה חשובה רק כשהעמית המיידי הוא פרוקסי מהימן. כתיבת שני הערכים ליומן מכריעה ויכוחים מאוחרים, משום שהעמית המיידי והכתובת המוחלפת הם עובדות שונות ורק אחת מהן הגיעה מהרשת.
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confבחרו את נקודת הכניסה הרצויה ותגרמו ל-DNS להסכים
אם האתר אמור להיות רק דרך המנהרה, תנו לו שם שמתפרש עבור לקוחות VPN לכתובת המנהרה ואכפו מדיניות בשקע המאזין. תשובת DNS מפוצלת שמחזירה 10.24.0.1 עבור השם הפנימי היא החלטת ניתוב בתחפושת של פרט בפתרון שמות. אם האתר צריך להיות גם ציבורי, החזיקו שני שמות או שני פורטים ותנו ליומן לומר איזה מהם שירת את הבקשה.
כללי ההרשאה הולכים אחרי אותו היגיון. הרשאה למאגר המנהרה אינה מקנה הרשאה לבקשה ציבורית והיא לא תמלא כתובת פנימית בחיבור שהגיע דרך האינטרנט. ערבוב שתי נקודות הכניסה תחת שם אחד הופך את המקור הנרשם לתופעת לוואי של ניתוב הלקוח במקום לבחירת תכנון.
אמתו את המסלול, ואחר כך את המדיניות
אשרו את המסלול בלכידה בשער ובבקשה שאתם שולטים בה. לכידה בהתקן המנהרה ואחת בממשק הציבורי מראות איזו מהן נשאה את הבתים, וסדר החבילות אומר לכם אם התרחש תרגום ביניהן.
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5לאחר מכן אמתו גישה בשני הכיוונים: נקודת הכניסה בעלת השם המיועדת עובדת עבור הלקוח המיועד, ומסלול ציבורי שאינו מאושר נדחה ולא רק איטי. אתר הד IP גנרי מוכיח משהו על יציאת השער לאינטרנט וכלום על האתר הזה באותו מארח. כשדף ו-WebSocket אינם מסכימים, השוו את כתובות ה-URL, משפחות הכתובות ותשובות ה-DNS שלהם לפני שאתם נוגעים בתצורת השרת.