האם לקוח VPN בשרת האינטרנט שלך שובר את התגובות שלו?

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

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

התסמין: הוא עונה מקומית ולא מבחוץ

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

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

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

למה בורר מקור באמת מתאים

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

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

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

בדוק את נתיב החזרה ואת התעבורה שלא התכוונת אליה

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

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

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

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

החלט כמה צרה יכולה להיות החריגה

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

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

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