חומת אש בענן מול חומת אש במארח עבור שרת VPN
שני מסננים שומרים על אותו פורט VPN. עברו את סדר הגבולות ממדיניות הענן ועד המאזין במארח, ואז הוכיחו את התיקון עם סשן חדש.
אפשרו את פורט ה-VPN במדיניות הענן והלחיצה עדיין עלולה למות במופע: המארח מריץ מסנן משלו וכריכת מאזין משלו, וכל אחד מהם עלול לזרוק את מה שהענן אישר. גם ההפך קורה, כשחוק במארח מתיר את הפורט ומדיניות מעליו זורקת אותו קודם. שני בעלים, שתי ערכות חוקים, נתיב חבילות אחד. עברו אותו לפי הסדר במקום לנחש בשכבה החשודה ביותר.
התחילו בקצה והתקדמו פנימה
הסדר קבוע: נקודת קצה ציבורית, ממשק משאב, מדיניות ענן מצורפת, כתובת המארח, מאזין התהליך, חוקי קלט מקומיים. כל שלב מעביר את החבילה או מסיים את החקירה, ולכן התחלה במארח מבזבזת את מירב הזמן.
תעבורת לקוח מועברת היא שלב נפרד, שנבדק לאחר פירוק המנהור. שכבת הענן רואה רק את המנהור החיצוני, ולכן היא יכולה לאשר חיבור ובכל זאת לא להיות קשורה לבקשת שירות פנימית. מנהור שמתחבר אך אינו מגיע למארח פנימי מצביע בדרך כלל על העברה, לא על פורט סגור.
קראו את מדיניות הענן לפני שנוגעים במארח
אשרו את חוק הכניסה לפורט ה-VPN, את הפרוטוקול שלו ואת טווח המקור שמתאים ללקוח הבדיקה שלכם. בדקו גם את רשימת בקרת הגישה של תת-הרשת: מסנן שני עם חוקים וברירות מחדל משלו. שניהם חייבים לאשר את הזרימה לפני שחבילה מגיעה למופע. אישור באחד ודחייה בשני הוא הצורה הרגילה של התקלה הזאת.
צמצמו את הטווח עד שהוא אומר משהו. פתיחת פורט ה-VPN לכל האינטרנט קלה להוכחה וקשה להגנה, ואילו חוק שנעצת לכתובת אחת נשבר כאשר לקוח הבדיקה שלכם עובר רשת. רשמו את מזהה החוק ואת בעל המדיניות, כדי שהשינוי הבא יהיה ניתן לאיתור לאדם.
אשרו את המאזין, ואז את שרשרת הקלט
במופע, בדקו שתהליך ה-VPN כרוך לכתובת ולפורט שאתם מצפים להם, למשל בעזרת ss -lntp 'sport = :1194'. תהליך שרץ ברקע וכרוך רק ל-127.0.0.1 מקבל לקוחות מקומיים ושום דבר דרך המנהור, מה שמבחוץ נראה בדיוק כמו פורט מסונן.
לאחר מכן קראו את החוקים המקומיים בתחביר שבו הייתם משתמשים כדי לשנותם, כגון iptables -S INPUT או nft list chain inet filter input. חוק שנכתב לקובץ אך מעולם לא נטען, או דחייה כברירת מחדל בלי אישור מתאים, זורק חבילות בשקט. בשער שמעביר תעבורה, בדקו גם את הגדרות ההעברה ואת נתיב החזור. הן קובעות מה קורה לחבילות שמנותבות דרך המופע ולא נשלחות אליו.
עם מצב בשכבה אחת, בלי מצב בשכבה הבאה
קבוצות אבטחה זוכרות את הזרימות שהתירו ומכניסות את התגובות חזרה. רשימות בקרת גישה של תת-רשתות וחומות אש רבות במארח אינן שומרות מצב כזה, ולכן חוק שמכסה רק את כיוון היציאה מעביר את הבקשה וזורק את התגובה. לעולם אל תעבירו הנחה לגבי תעבורת חזור בין שכבות בלי לקרוא את החוק של השכבה השנייה (second layer's rule).
מונה מהיר יותר מלקרוא כל חוק בחשבון. מונה שעולה אומר שהחבילה הגיעה ונזרקה שם, ואילו מונה קפוא על אפס אומר שהיא מעולם לא הגיעה לשם; iptables -vnL INPUT ו-nft list ruleset מציגים את המספרים האלה כשהחוקים נטענו עם מונים.
בדקו בסשן חדש, לא בסשן חי
השאירו את רשת המקור ואת פרופיל הבדיקה כמו שהם כשאתם משווים תצוגות, ופתחו חיבור חדש אחרי כל שינוי. הגעה לקונסולת הרשת ב-443 לא אומרת דבר על כך שהתהליך של VPN כרוך ל-1194, לכן בדקו את הפורט שאתם צריכים. סשן קיים הוא העד הגרוע ביותר כאן. הוא ממשיך לעבוד בזמן שכל כניסה חדשה נדחית.
לפני עריכת מדיניות מרוחקת, הבטיחו דרך חזרה שאינה תלויה בנתיב שאתם משנים. ואז פתחו סשן ניהול שני לצד בדיקת ה-VPN: סשן שנפתח קודם יכול לשרוד את החוק שחוסם חדשים. רשמו את שני בעלי המדיניות כדי ששום בנייה מחדש לא תשחזר חצי מהנתיב; אם שתי השכבות מסכימות והמנהור עדיין נכשל, תפסו בממשק של המארח ובדקו את הכתובת והפורט שבהם הלקוח באמת משתמש.