VPN בנתב או העברת פורט: מי מנצח?

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

פורט אחד, שני בעלים לכאורה

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

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

התרגום רץ לפני הבדיקה המקומית

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

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

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

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

השאירו מיפוי אחד והסירו את השני

רשמו את רשומות ה-NAT עבור הפורט והמשפחה האלה ובחרו את השורד:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

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

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

אשרו את הבעלים מבחוץ

בדקו כל משפחה בנפרד, כי חיבור IPv6 שמסתיים בנתב לא אומר דבר על חיבור IPv4 שכלל ישן מפנה מחדש. קראו את היומן של השירות המקבל כדי לראות איזו נקודת קצה ענתה, והתייחסו להודעת ההצלחה של הלקוח כראיה חלשה. נדרש זרם חדש לבדיקה משמעותית. שלחו בדיקה ממארח חיצוני עם nc -zvu 203.0.113.7 1194 וקראו את יומן המנצח עם journalctl -u openvpn@server -n 20. מאזין הנתב רושם את החיבור בעצמו, בעוד מארח ברשת המקומית רושם אותו בשירות שלו.

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

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