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

שני כללים עם מחזורי חיים שונים

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

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

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

מדוע הפעלה לא תפרסם שרת

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

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

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

מה העברה ממפה בפועל

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

RuleOpens whenCloses whenFits a VPN listener
Port forwardSaved, at bootYou delete itYes
Port triggerMatching outbound trafficIdle timeout or rebootNo

הפרוטוקול חשוב יותר ממה שהטופס מרמז. OpenVPN מעל UDP זקוק להעברת UDP, WireGuard זקוק ל-UDP, ונתוני IPsec מגיעים כ-ESP, פרוטוקול IP 50, שאין לו פורטים כלל. טופס העברה שמקבל רק TCP או UDP אינו יכול לבטא זאת, ולכן IPsec זקוק ל-passthrough או למיפוי סטטי אחד-לאחד במקום כלל פורט.

השכבה שמעל הנתב שלכם

העברה שולטת רק בתרגום שבבעלותכם. אם כתובת ה-WAN אינה שלכם, וזה המקרה מאחורי NAT של ספק שבו מנויים חולקים 100.64.0.0/10 כמתואר ב-RFC 6598, החיבור הנכנס לעולם לא מגיע לנתב שלכם מפני שהספק תרגם ראשון. שום כלל במכשיר שלכם לא יכול לתקן את הסדר הזה.

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

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

הגבילו את הכלל, ואז אמתו את שני החצאים

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

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

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

החליטו בשלוש שאלות

שלוש שאלות מכריעות את הבחירה מהר יותר מכל טבלת השוואה:

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

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

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