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

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

הכתובת שבאפליקציה אינה זו שמגיעה

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

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

עקבו אחרי בקשה אחת עד גבול הסינון שלה

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

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

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

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

אמתו את המסלול בלכידה מוגבלת אחת

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

tcpdump -ni any 'tcp dst port 9443' -c 20

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

קראו את סדר השרשרת, לא רק את הכלל

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

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

שנו את הכלל שבעליו שולט בו

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

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

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