אתר NGINX ל-VPN בלבד: מאזין, חומת אש ורשימת היתרי HTTP

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

הדוגמה משתמשת בשער Linux OpenVPN בכתובת 10.90.0.1 על tun0, בלקוחות ב-10.90.0.0/24, במקורות נשמרים וב-TCP 8443 השמור לכניסה הזו. התאימו את הערכים, שמרו על השכבות.

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

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

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

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

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

סגרו כל מאזין אחר לאותו תוכן

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

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

בדקו את שתי משפחות הכתובות. כריכת IPv4 משאירה שקע IPv6 בלתי נגוע, ורשומת A חדשה אינה מושכת חזרה תשובת AAAA ישנה שעדיין מצביעה על נתיב ציבורי.

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

הגבילו את הנתיב הנכנס במארח

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

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

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

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

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

שמרו על רשימת ה-HTTP שלמה כשהמיקומים משתנים

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

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

סקרו כל מיקום, כינוי ובלוק חלופי כחלק מאותה מדיניות. אם בדיקות IP משולבות באימות NGINX, הבינו את satisfy: הגדרת any יכולה להכניס לקוח דרך מנגנון אחד בעוד האחר לא עבר. הכניסו את רשימת הגישה לרשימת הבדיקה של המיקומים.

דחיית HTTP מתרחשת לאחר שחיבור ה-TCP מגיע ל-NGINX. היא משלימה את הגבלת הרשת, וההרשאה של היישום עצמו עדיין חלה על כל משתמש.

אמתו את הנתיב החי ואת מקרה הכשל

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

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

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

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