האם VPN מסחרי חוסם את פורט 5432? השוו את האפשרויות שלכם

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

הבדיקה בת חמש הדקות שמפרידה בין סינון לכל דבר אחר

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

Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432

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

אפשרות ראשונה: מנהרה מפוצלת עבור תת-הרשת של מסד הנתונים

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

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

אפשרות שנייה: נקודת הקצה שלכם, היציאה שלכם

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

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

אפשרות שלישית: הוציאו את המחשב הנייד מהנתיב

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

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

למה הוספת הכתובת של הספק לרשימת ההיתר היא ההשוואה השגויה

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

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

יהיה מה שתבחרו, רשמו את הנתיב ואת הסיבה. האדם הבא יפגוש את אותו חיבור מתאפס ויתחיל להאשים את היישום.