NEW של conntrack על מנת ACK: מה זה לא מוכיח
ACK המסומן NEW פירושו שלעוקב לא היה מצב תואם, ולא שה־VPN פתח הפעלה. קראו את ה־hook, את ה־tuple ואת חלון הלכידה.
ביומן חומת האש יש שורה שלא ציפיתם לה: מנת ACK, מצב conntrack NEW, כתובת מקור שאינה שלכם, פורט יעד פתוח. הפיתוי הוא לקרוא אותה כחיבור נכנס חדש שאיש לא אישר. מה שהשורה באמת אומרת הוא צר יותר: כשהמנה הזאת הגיעה ל־hook הזה, לעוקב לא היה מצב תואם, והמנה נשאה ACK. אלה שתי עובדות על שני דברים שונים, ואף אחת מהן אינה תמליל מלא של לחיצת יד. זה הסדר שאני עובר לפני שאני מגיע למסקנה.
התחילו מהמנה, לא מהפסיקה
הפרידו בין התצפיות לפני שאתם מפרשים אותן. דגלי TCP מתארים את המנה הזאת, מצב העוקב מתאר מה הוא ידע ב־hook הזה, והלכידה שלכם מתארת רק את החלון שהקלטתם.
ערבוב שלושת אלה הוא הדרך שבה ACK הופך ל״הספק הכניס מישהו פנימה״.
מה NEW באמת אומר ב־hook
התאמת conntrack של iptables מתעדת NEW כמנה שמתחילה חיבור, או מנה שמשויכת לחיבור שעוד לא ראה תעבורה בשני הכיוונים. ESTABLISHED פירושו שהעוקב ראה מנות בשני הכיוונים. אף אחת משתי ההגדרות לא אומרת שהמנה הייתה SYN, ואף אחת לא אומרת שהיא הגיעה בלי היסטוריה.
עוקב שמתחיל לצפות בזרימה מהאמצע מסווג את המנה הבאה לפי מה שהוא יודע, וזה יכול להיות כלום. זו אמירה על הזיכרון של העוקב, לא על הכוונה של המארח המרוחק.
מעקב רופף מסביר את רוב ההפתעות עם ACK
הגרעין מתעד nf_conntrack_tcp_loose, מה שמאפשר לעוקב לקלוט חיבורי TCP שלא ראה את תחילתם. כשההגדרה בערך ברירת המחדל שלה, ACK מאמצע זרימה יכול להתקבל כזרימה מבוססת. כבו אותה והמנה הזאת עצמה תסווג כנראה כ־INVALID ולא כ־NEW. שתי התוצאות מתארות את הכללים של העוקב, לא את ההיסטוריה של היישום.
לכן בדקו את ההגדרה הזאת לפני שאתם בונים תיאוריה על התווית.
שללו את הסיבות המשעממות בסדר הזה
רוב אירועי ה־NEW על ACK שעקבתי אחריהם הסתיימו באחת מאלה, וכולן זולות לבדיקה:
- טבלת conntrack נוקתה, או שהעוקב הופעל מחדש.
- המארח הופעל מחדש, או שהזרימה עברה ל־namespace או להתקן אחר.
- ניתוב לא סימטרי הוציא את ה־SYN במסלול שאינכם לוכדים.
- NAT כתב מחדש את ה־tuple, ולכן הרשומה כבר לא תואמת את מה שקראתם.
- הלכידה התחילה מאוחר ולא ראתה את ההתחלה מעולם.
כל אחת מאלה מסירה את המנות המוקדמות מעיניו של העוקב ומשאירה את המאוחרות שלמות. הפעלה מחדש או ניקוי טבלה הם הקלים ביותר לאישור מתוך uptime והיומנים. ניתוב לא סימטרי נראה כלכידה חד־כיוונית. NAT הוא הערמומי, כי ה־tuple שהעוקב שמר אינו ה־tuple שהודפס ביומן.
רשמו אילו מהן שללתם, ואיך, לפני שתמשיכו.
קראו את ה־tuple, את הממשק ואת ה־hook
רשומת conntrack ממופתחת לפי כתובות, פורטים ופרוטוקול, ולכן כל תרגום משנה איזו רשומה תואמת. רשמו גם את הממשק ואת ה־hook, כי מנה שנראית בממשק הלא נכון או אחרי שרשרת אחרת אומרת שהמסלול אינו זה שבאיור. כשהאירוע נוגע ל־VPN, החליטו אם אתם מביטים במנה הפנימית או בנושא החיצוני. אחר כך השוו למה שהשער תיעד עבור אותו tuple בן חמישה חלקים.
שתי תצוגות של זרימה אחת שאינן מסכימות מועילות יותר מכל אחת מהן לבדה.
מתי שווה להסלים
הסלימו כשאתם יכולים להראות שירות שנגיש ושאינו אמור להיות, יחד עם הזרימה, המדיניות שאישרה אותה והוכחות משני הקצוות. אל תדווחו על פגם של ספק על סמך תווית מצב אחת או לכידה חלקית אחת, כי הדיווח הזה ייסגר עם ההסבר שקראתם זה עתה. אם השירות באמת חשוף, הבעלים של אותו גבול הוא האדם הנכון לתקן אותו, ומיפוי פורט שהואצל או מאזין לא מכוון הם סיבה סבירה יותר מבאג.
אחר כך סתמו את פער הנראות שאפשר למנה אחת להיראות כמו הפעלה שלמה.