איפוס TCP אינו מוכיח שה-VPN שלך נחסם
איפוס מסיים חיבור TCP, אבל יומן הלקוח לא יכול לומר מי שלח אותו. תעד את השלב, השווה את שני הקצוות ובדוק משתנה אחד בכל פעם.
„החיבור אופס, מאתחל“ מופיע ביומן הלקוח, והמסקנה מגיעה לפני הראיה. מישהו מחליט שהרשת חוסמת את ה-VPN, או שהתעודה שגויה, או שמדינה מסוימת מתערבת. איפוס הוא מקטע TCP שמסיים חיבור, ושורת היומן מתעדת שהלקוח שלך קיבל אחד. היא לא מציינת את ההתקן ששלח אותו ולא את הסיבה.
איפוס הוא מקטע, לא פסק דין
TCP מגדיר את עיבוד האיפוס: מקטע עם דגל RST מסיים את החיבור מיד. המקבל לא מנהל משא ומתן, לא מנסה שוב ולא שואל מדוע. הוא מדווח על האיפוס וממשיך הלאה.
זה כל מה שהלקוח יודע. ה-RST יכול היה להגיע מהשרת, מפרוקסי, מחומת אש או ממאזן עומסים שאיבד את מצבו.
ייחוס המקור הוא תרגיל נפרד. כתובת מקור לכאורה בקובץ לכידה אינה הוכחה למקור הפיזי, והיא לא אומרת דבר על החלטת המדיניות שמאחוריה. התקנים מתווכים יכולים לזייף כתובות, והתקנים בעלי מצב יכולים לאפס בגלל פסק זמן ולא בכוונה. התייחסות לאיפוס כפסק דין מדלגת על החלק שבו מגלים את האמת.
אשר איזה חיבור אופס
תחילה בדוק שהפרופיל הפעיל באמת משתמש ב-TCP. איפוס במנהרת UDP חסר היגיון, ויומן של פרוקסי HTTP יכול להתייחס לרגל TCP אחרת מזו של ה-VPN עצמו.
תעד את היעד, את הפורט, את זמן הניסיון ואת השלב שאליו הגיע הלקוח.
השלב הוא השדה השימושי ביותר. איפוס במהלך לחיצת היד של TLS מצביע על קבוצת חשודים אחת; איפוס לאחר אימות מצביע על אחרת. בלי השלב, כל תיאוריה מתאימה.
השווה את שני קצוות הנתיב
אם אתה מנהל את השרת, השווה את האירועים שלו לאותו ניסיון. האם הוא קיבל את החיבור? האם סגר אותו בכוונה? האם תשובה עזבה גבול אחד ולא הגיעה לבא בתור?
לכוד בלקוח ובשרת אם אתה יכול. איפוס שמופיע בלקוח אך לא בשרת לא נוצר בשרת.
שימו לב למקטעי RST בשני הכיוונים:
sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20צמצם באמצעות השוואה מבוקרת
רשת שנייה מאושרת יכולה לומר לך אם הכשל עוקב אחרי הלקוח או אחרי הנתיב. אם אותו פרופיל עובד במקום אחר, תצורת הלקוח כנראה תקינה והנתיב הוא המשתנה.
זה עדיין לא מזהה התקן מתווך מסוים. זה מצמצם את ההיקף לנתיב, וזו תוצאה שימושית וכנה.
שמור על ההבחנה בין „הנתיב הזה נכשל“ לבין „השחקן הנקוב הזה גרם לכך“. הראשון ניתן לבדיקה; השני בדרך כלל לא מלקוח בודד.
בדוק את התיקון בלי לשנות הגדרות אמון
אל תבטל את אימות TLS, אל תייצר אישורים מחדש ואל תכריז על מדיניות חסימה על סמך שורת איפוס אחת. כל אחד מהשינויים האלה משנה את המערכת הנבדקת והופך את ההשוואה הבאה לחסרת משמעות.
תקן את הרכיב שזוהה דרך הבעלים שלו, ואז חזור על אותו פרופיל ועל אותה תצפית:
openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40התוצאה השימושית היא כשל שממוקם טוב יותר, לא סיפור בטוח יותר. אם האיפוס נעלם לאחר תיקון הפרוקסי, יש לך סיבה. אם הוא עובר לשלב אחר, למדת משהו על הנתיב. כך או כך, הראיה צריכה לשרוד קריאה של אדם שני. רשום מה צפית, לא מה הסקת.