איזו כתובת נכנסת ל-DNS עבור שרת שמחובר דרך VPN?
לשרת מתארח יש שלוש כתובות והן אינן ניתנות להחלפה. בחרו את הערך שכל שירות צריך, ואז אמתו אותו מחוץ למכונה.
שרת מתארח עם VPN מותקן מחזיק בסופו של דבר שלוש כתובות, ורק אחת מהן שייכת לכל מקום שאתם עומדים להגדיר. העתקת המספר מלוחית של ספק אל ה-DNS, אל מאזין או אל רשימת הרשאות היא הדרך שבה מנהרה שעובדת הופכת לשירות שאיש אינו יכול להגיע אליו. המדריך הזה מסדר את העבודה כך שכל כתובת נבחרת למטרה מוצהרת. הוא גם מפרט את הפקודות שמאשרות מה באמת פרסמתם.
מפו את שלוש הכתובות לפני שאתם מפרסמים משהו
תנו להן שמות לפי תפקיד. כתובת ה-underlay היא מה שהמכונה משתמשת בו כדי להגיע לנקודת הקצה של ה-VPN דרך האינטרנט, והיא לרוב פרטית מאחורי ה-NAT של הספק. כתובת המנהרה חיה בתוך ה-VPN, ומוקצית על ידי השרת או הלקוח בהתאם למוצר. היציאה הציבורית היא הכתובת שאתר מרוחק רושם לאחר התרגום, והיא אינה חייבת להתקיים באף ממשק שתוכלו לשאול עליו.
לוחית שמציגה כתובת ציבורית אחת עבור מכונה אומרת לכם מעט מאוד על שני התפקידים האחרים. נגישות ה-underlay היא דרישה, לא רכישה: מחשב נייד מאחורי נתב ביתי יכול להגיע לנקודת קצה מתארחת של VPN בלי להחזיק בכתובת IPv4 ציבורית. מה שאינכם יכולים לעשות הוא להמציא נתיב נכנס על ידי כתיבת שם שמתרגם לכתובת שאיש אינו מעביר.
בחרו את הכתובת לפי השירות, לא לפי התווית
רשמו מה השרת חייב לעשות לפני שתבחרו מספר. קריאות API יוצאות זקוקות ליציאה יציבה כשהצד השני מחזיק רשימת הרשאות. גישה פרטית זקוקה לכתובת מנהרה שאליה הלקוחות יכולים לנתב ולמאזין שמקושר אליה. אירוח ציבורי זקוק למיפוי נכנס שהספק באמת מציע, וכתובת היציאה לבדה אינה מספקת אותו.
מכונה אחת יכולה לשרת את שלוש המטרות ועדיין להשתמש בשלוש כתובות שונות. מה שנשבר הוא ההנחה שערך אחד מכסה את כולן:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
השורה הנכנסת היא זו שאנשים מתווכחים עליה. רשומה שמצביעה על כתובת היציאה אינה יוצרת מאזין, פתח בחומת אש או מיפוי פורט, והמתנה לא משנה זאת. כשהספק מוכר כתובת ייעודית יחד עם כלל נכנס, החבילה הזו היא היכולת שקניתם; הכתובת לבדה אינה הזכות.
פקודות שמראות איזו כתובת היא איזו
קראו את המכונה, לא את הלוחית. שמות הממשקים שונים בין מערכות, אז התאימו כתובות להתקנים במקום לסמוך על תווית.
השורה הראשונה מפרטת כל כתובת IPv4 ואת ההתקן שלה, והשנייה שואלת את הליבה באיזה התקן היא תשתמש ליעד חיצוני מוכר:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'אם חיפוש הנתיב עונה בהתקן מנהרה עבור תעבורה ציבורית, המנהרה המלאה שלכם בתוקף. בדיקת המאזין חשובה באותה מידה, כי תהליך שמקושר רק ל-127.0.0.1 לעולם לא יענה על כתובת המנהרה, איזה שם שלא תפרסמו.
פרסמו אותה, ואז אמתו מבחוץ
פרסמו את הערך שהשירות צריך ולא יותר: רשומת A או AAAA לאירוח, רשומה ברשימת ההרשאות לקריאות יוצאות, פרופיל לקוח לגישה פרטית. אחר כך בדקו מהמיקום שמשנה, וזה לעולם אינו המכונה שזה עתה ערכתם.
שתי בדיקות מכסות את רוב המקרים, ושתיהן זולות מספיק כדי להישאר בסקריפט:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthתשובת DNS שמוכיחה שהרשומה שלכם קיימת אינה הוכחה שבקשה מגיעה, ובקשה מוצלחת אחת מוכיחה רק שנתיב אחד עובד מרשת אחת. חזרו על הבדיקה מחיבור סלולרי כשמעורבת רשימת הרשאות, כי היציאה שאתם רואים עשויה להיות תלויה במשפחת הכתובות ובנתיב שנבחר. רשמו איזו משפחה אימתתם; נתיב IPv4 שעובד אינו אומר דבר וחצי דבר על IPv6.
אם השירות נכנס, כתובת היציאה אינה מספיקה
גישה נכנסת צריכה ארבעה דברים בקו אחד: שם או כתובת שלקוח יכול להגיע אליהם, נתיב שמעביר את החבילה למכונה, מאזין שמקבל אותה ומדיניות שאינה מפילה אותה. VPN משנה את הרכיב השני ולפעמים את הראשון, ולשלישי ולרביעי הוא לא עושה דבר. כשהמנהרה היא נתיב האספקה, הלקוחות מתחברים לכתובת המנהרה, לא ליציאה.
רשמו מאיזו כתובת תלוי כל שירות, ואז עברו על הרשומה הזו בכל פעם שהספק משנה את מודל הניתוב שלו. שרת שעונה באופן פרטי ונכשל באופן ציבורי בדרך כלל אינו שבור; הוא עונה תחת זהות שגויה, והתיקון הוא החלטת מיפוי ולא שינוי בחומת האש.