pfSense כשרת VPN וכלקוח: שני מסלולים, נתב אחד

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

קראו בשם לשני התפקידים לפני שנוגעים בהגדרה

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

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

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

השאירו את תשובות השרת על נתיב ה-WAN

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

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

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

אל תתנו למנהרת היציאה לאכול את נקודת הקצה של עצמה

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

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

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

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

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

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

השביתו את מופע הלקוח, ראו למה משתמש מחובר עדיין מגיע, ואז הפעילו אותו שוב. בקשה שפגה בזמן היא תוצאת החסימה המלאה שביקשתם; זו שעונה בכתובת ה-WAN היא הנפילה חזרה שלא תיעדתם. חזרו על הבדיקה עבור IPv6 ועבור DNS, מפני שמדיניות שנכתבה עבור IPv4 אינה אומרת דבר על תעבורה של AAAA ומפענח שדוחף מי מהמנהרות עונה מהמקום שממנו השאילתה באמת יוצאת.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

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