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

מה הנתב באמת עושה

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

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

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

NAT ו-NAT-T קובעים את המסלול

IPsec לא נבנה כדי לשרוד תרגום כתובות, ולכן התקנים הוסיפו מעטפת. NAT traversal עוטף את ESP בתוך UDP, ומאפשר לטבלת NAT רגילה לשאת את הזרימה, והמשא ומתן מסכים על המעבר הזה במהלך IKE (RFC 3948). IKE עצמו משתמש ב-UDP 500, בעוד שהנתיב העטוף משתמש בדרך כלל ב-UDP 4500.

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

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

מצאו את השלב שנכשל

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

sudo tcpdump -ni any 'udp port 500 or udp port 4500'
ip xfrm state list
ip xfrm policy list

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

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

כבו את מה שאין לכם צורך בו

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

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

מאמרים קשורים