היכן לעקוב אחר התעבורה של לקוח OpenVPN בשער

אתם רוצים לדעת לאילו יעדים מגיע לקוח מחובר, ולכן פותחים מעטפת בשרת ה-VPN ומקלידים ss. שום דבר שימושי לא מופיע, והמסקנה שהמנהרה שבורה מגיעה קצת יותר מדי בקלות. שער OpenVPN מנותב מעביר את המנות של הלקוח; הוא לא מסיים את חיבורי ה-TCP שלהם ואין לו sockets עבורם. הראיה חיה במקום אחר, ואיזה מקום תלוי באופן שבו התעבורה מטופלת לאחר שהיא יוצאת מהמנהרה.

החליטו איזו סידור אתם רואים

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

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

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

קשרו קודם את הכתובת לסשן

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

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

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

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

קראו את טבלת הזרימות בשער מנתב

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

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

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

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

לכידה מוגבלת אחת כדי לאשר את הקריאה

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

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

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

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

יומני פרוקסי, וגבולות מה שראיתם

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

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

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