שער VPN על Raspberry Pi: כרטיס רשת אחד או פורט לקוח ייעודי
פורט אחד של Pi יכול לשרת לקוחות נבחרים, או שפורט שני יכול לסגור את המכשירים בפנים. בחרו פריסה לפי בידוד, מדיניות נפילה לאחור ומי מחזיק ב-DNS.
יש לך Pi אחד, פרופיל VPN יוצא שעובד, ושני מכשירים שאמורים להגיע לאינטרנט דרכו. השאלה שמכריעה את כל הבנייה אינה איזו מדריך לעקוב אחריו, אלא כמה בידוד אתה צריך. פורט אחד מאפשר ל-Pi לשבת לצד אותם מכשירים ב-LAN של הנתב ולשמש כשער נוסף; פורט שני מאפשר לך לשים אותם במקטע שבו ה-Pi הוא הדרך היחידה החוצה. כל מה שאחרי הבחירה הזו — DHCP, היקף חומת האש, DNS, מקרה הנפילה — נובע ממנה.
במה שתי הפריסות באמת נבדלות
שתי התוכניות מנתבות. ההבדל הוא מי עוד נמצא על הכבל ומה קורה כשהמדיניות שלך שגויה.
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
הבידוד הוא הציר האמיתי. פריסה A היא מייעצת: מכשיר שמתעלם מהשער שסופק ב-DHCP ובוחר בנתב עדיין עובד, אך ללא הצפנה. פריסה B נאכפת על ידי הטופולוגיה, כי אין קפיצה הבאה אחרת לבחור בה.
פריסה A: ה-Pi כשער נוסף ב-LAN הקיים
נניח שהנתב של ספק האינטרנט הוא 192.168.50.1, שה-Pi הוא 192.168.50.2, ושהלקוחות הנבחרים מצביעים על ה-Pi. החשוב הוא ששני זרמי מנות שונים חולקים כבל אחד. המנה הפנימית של הלקוח מגיעה ל-Pi וחייבת לצאת דרך המנהרה; המנה המוצפנת של ה-Pi עצמו אל עמית ה-VPN חייבת לצאת דרך אותו כבל אל הנתב. הם נעים בכיוונים מנוגדים על אותו ממשק וזקוקים לטיפול שונה.
תן ל-Pi את הכתובת שלו דרך מנהל הרשת המותקן, ולא דרך מתכון ישן של קובץ ממשק שמתחרה בו על המכשיר. לאחר מכן הגדר את הלקוחות: שער סטטי במכשיר אחד, או הזמנת DHCP שמחלקת את 192.168.50.2 כנתב. אל תשנה את כל טווח ה-DHCP של הנתב בגלל שני מכשירים, ואל תניח שלקוח מכבד את האפשרות — אמת זאת.
החולשה מבנית ולא ניתנת לתיקון. כל לקוח במקטע הזה יכול להצביע על 192.168.50.1 ולצאת בטקסט גלוי, ומכשיר עם ממשק שני או רדיו סלולרי עוזב את נתיב האכיפה שלך לגמרי. אם המשפט הזה אינו מקובל על המכשיר המדובר, כבר יש לך את התשובה: השתמש בפריסה B.
פריסה B: פורט ייעודי סוגר את המכשירים בפנים
כאן ה-Pi שומר על 192.168.50.2 בקישור העולה עם שער 192.168.50.1, ולוקח 10.20.0.1/24 בממשק שני עבור המכשירים המחוברים. כעת ה-Pi הוא נתב עם שתי רשתות, ולמקטע המחובר יש יציאה אחת בדיוק.
בדוק את הטווח מול כל דבר אחר לפני שאתה מתחייב: תת-הרשת של המנהרה עצמה, קידומות אחרות בין אתרים, וכל מה שניתן להשיג דרך ה-VPN. 10.20.0.0/24 שמתנגשת ב-LAN מרוחק מייצרת את אותה תוצאה חצי-עובדת שלוקח ערב לאבחן. אם הפורט השני הוא מתאם USB, ודא שהוא נתמך ונעץ את שמו במנהל הרשת כדי שסידור מחדש לאחר אתחול לא יזיז את כתובת ה-LAN שלך.
הרץ את מאזין ה-DHCP רק בממשק הזה. שרת שעונה בקישור העולה מתחרה בנתב של ספק האינטרנט ומחלק את כתובות המקטע שלך לשאר הבית. קשר אותו לממשק ה-LAN, הגבל אותו לטווח המוצהר, והחזק את הכתובת של ה-Pi עצמו מחוץ למאגר.
העברה, תרגום וכלל הסגירה בעת כשל
ארבעה דברים מתוארים לעתים קרובות כאחד ואינם. הפעלת העברה (net.ipv4.ip_forward=1) רק אומרת לליבה שהיא רשאית להעביר מנות בין ממשקים; היא בעצמה אינה מתירה דבר ואינה מבטיחה שום נתיב. בחירת היציאה היא החלטת ניתוב. התרת המנה היא החלטת מדיניות בשרשרת forward. שכתוב המקור שלה הוא החלטת postrouting. בנייה שעושה רק את הראשון מייצרת Pi שמעביר בשמחה תעבורת לקוחות החוצה בקישור העולה.
הגבל את ההרשאה למקורות שהתכוונת אליהם ולממשק שהתעבורה אמורה להשתמש בו, וכלול את נתיב החזרה ואת היעדים הנדרשים של ה-Pi עצמו. לאחר מכן תרגם ביציאה של המנהרה אם הספק אינו מנתב את קידומת ה-LAN שלך חזרה אליך. המדריך של nftables מתייחס להעברה, לפלט מקומי ולתרגום מקור כפעולות נפרדות, וזהו מודל החשיבה הנכון כאן.
הכשל הנפוץ הוא כלל masquerade רחב בממשק הפיזי. אז התעבורה מגיעה לאינטרנט דרך נתיב ספק האינטרנט בעוד שמצד הלקוח היא נראית בדיוק כמו VPN שעובד. זה לא מוכיח דבר. החזק את התרגום קשור ליציאה המוצהרת, והחזק את הכללים שלך בחומת האש שהמארח כבר משתמש בה במקום להוסיף סט כללים מתחרה שרוקן שרשרת postrouting משותפת.
לאחר מכן טפל בהיעדר המנהרה. פרופיל לקוח שמתקין נתיב ברירת מחדל רחב אומר גם שכאשר המנהרה נופלת, ברירת המחדל הרגילה יכולה לחזור והתעבורה של הלקוח שבה בשקט לקישור העולה. היכן ש נפילה לאחור לטקסט גלוי אינה מקובלת, מדיניות ה-forward חייבת לחסום במפורש תעבורה מלקוח לקישור העולה, במצב שבו נתיב ה-VPN נעלם. כתוב זאת ככלל דחייה, לא כהנחה. התעבורה המוצפנת של ה-Pi עצמו אל עמית ה-VPN היא זרם local-output נפרד וחייבת להישאר מותרת, אחרת המנהרה לא תוכל לחזור לעולם.
ל-DNS ול-IPv6 יש תשובה משלהם
אם לקוחות משתמשים ב-Pi כרזולוור, הם פוגעים במאזין מקומי וה-Pi יוזם שאילתה חדשה. שאילתה עולה זו עוקבת אחר הנתיב של ה-Pi עצמו, לא אחרי כלל ה-forward שכתבת ללקוחות, ולכן נתיב לקוח רק דרך המנהרה בתוספת רזולוור שיוצא ישירות הוא דליפה בלי שום הודעת שגיאה. החלט בכוונה: רזולוור שמושג דרך המנהרה, או רזולוור מקומי שאתה מקבל כישיר, והתאם את מדיניות היציאה של ה-Pi עצמו להחלטה הזו.
IPv6 הוא שוב מקרה נפרד. כלל forward של IPv4 אינו מגביל דבר בנוגע ל-IPv6, והכרזות נתב בקישור העולה יכולות לתת ל-Pi, ודרכו למקטע המחובר, ברירת מחדל שנייה שעוקפת את המדיניות שלך. או תן ל-IPv6 נתיב מוגן משלו על אותו עיקרון, או הגבל אותו במפורש במקטע הלקוחות ואמור זאת.
בדוק את הגבול לפני שאתה סומך עליו
קבל את העיצוב רק לאחר ארבע בדיקות נפרדות, כי הבדיקה הבודדת המפתה — לפתוח דפדפן בלקוח אחד — עוברת בכמה מצבים שבורים.
ודא שלקוח אמיתי אחד מגיע לאינטרנט דרך המנהרה, ואז ודא שאותו לקוח אינו יכול להגיע לאינטרנט כשהמנהרה למטה. ודא שפתרון ה-DNS עובד ושהשאילתה יוצאת לאן שהתכוונת. ודא שהתעבורה של ה-Pi עצמו עדיין פועלת לאחר אתחול המנהרה, ושהשחזור אינו דורש אתחול של המכונה. לבסוף, בדוק מכשיר שלא בחרת: בפריסה A הוא אמור להמשיך לעבוד כרגיל, ובפריסה B הוא לא אמור להתקיים במקטע הזה בכלל.
- שני פורטים וכלל דחייה נותנים אכיפה; פורט אחד ואפשרות DHCP נותנים עצה.
- תרגום בממשק הלא נכון נראה כמו הצלחה ואינו כזה.
- התעבורה של ה-Pi עצמו, ה-DNS וה-IPv6 כל אחד מהם צריך החלטה, לא הסקה.