מדוע VPN מסוג TAP משותף עדיין זקוק ל-HTTPS בפורטל
VPN מסוג TAP מאמת את העמית, לא את השירות שמאחוריו. שמרו על אימות שם המארח בפורטל ובודדו שכנים שאינכם בוטחים בהם.
לשני מכשירים יש אישורי VPN תקפים והם חולקים מקטע Ethernet מגושר אחד. רק אחד מהם אמור לענות עבור פורטל המשרד, והשני עדיין יכול לתבוע את כתובת הפורטל באותו מקטע. המנהרה עשתה את שלה: היא אימתה את שני העמיתים והצפינה כל נתיב לשרת. מה שהיא לא עשתה הוא להעיד למי מהם יש שם שירות, והפער הזה הוא הסיבה שהפורטל עדיין זקוק לתעודה תקפה.
מה ה-VPN באמת מאמת
לחיצת יד של VPN עונה על שאלה אחת: איזה עמית השלים את המנהרה הזו, ובאיזה חומר מפתח. התשובה הזו היא לכל עמית ולכל חיבור, והיא לא אומרת דבר על השירותים שהעמית הזה חושף לאחר מכן. במקטע TAP העמית אינו אפילו כתובת אחת, כי הוא יכול להציג כל MAC וכל IP שהגשר מוכן ללמוד. האימות נעצר בקצה המנהרה, לא ביישום.
הפרידו בין שלוש השאלות במקום למזג אותן לאחת. לכל אחת מנגנון משלה ואופן כשל משלה.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
פריסה יכולה להחזיק מנהרה מאומתת לחלוטין ושירות בלתי מאומת לחלוטין מאחוריה. היא יכולה גם להחזיק תעודה מאומתת על מארח שכתובת השכבה השנייה שלו נתבעת על ידי עמית אחר, ולכן שני הבקרות שייכות לתכנון ולא אחת במקום השנייה. הטבלה היא כל הטיעון בשלוש שורות.
ARP במקטע משותף אינו מדריך
ARP ממפה כתובת IPv4 לכתובת MAC בקישור המקומי ומקבל תשובות מכל מי שבאותו קישור. במקטע מגושר מתירני עמית יכול לתבוע כתובת ששייכת למכשיר אחר, והגשר מעביר מסגרות למי שהשיב לאחרונה. הצפנת כל נתיב לקוח לשרת אינה משנה זאת, כי המסגרות מפוענחות לפני שהן מגיעות לגשר. גבול האמון של ARP הוא המקטע, לא המנהרה.
הביטו במה שהמארח באמת למד: ip neigh show מציג את המיפויים הנוכחיים ואת מצבם, ורשומה שמתחלפת בין שתי כתובות MAC בפעולה רגילה היא סימפטום שכדאי לחקור ולא להתעלם ממנו. במקטע קטן ובריא הרשומות האלה נשארות יציבות זמן רב.
בידוד עמיתים ומדיניות הגשר קיימים בדיוק למקרה הזה. תכנון מנותב הוא בדרך כלל התשובה הטובה יותר כשהשירות הוא IP בלבד ולמכשירים אין שום סיבה לראות את המסגרות זה של זה.
השאירו את אימות התעודה במקום שבו נמצא השירות
ה-TLS של היישום עונה על השאלה שהמנהרה לא יכולה: האם זה השירות שאליו רציתי להגיע. הדפדפן בודק את שם המארח מול התעודה, והבדיקה הזו היא החלק היחיד בשרשרת שמזכיר את הפורטל ולא את העמית.
בדקו מה השרת מציג לפני שתחליטו שהאזהרה קוסמטית. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal מדפיס את השרשרת ואת השמות החלופיים של הנושא. אם השם שהקלדתם אינו ברשימה הזו, האזהרה נכונה והתעודה היא שצריך לתקן. לימוד משתמשים לדלג עליה הופך בקרה עובדת לקישוט.
מדריך הגישור של OpenVPN מתאר את מודל ה-Ethernet ואת אפשרויות המדיניות שסביבו, וזהו המקור הנכון למה שהמקטע אמור להתיר. קראו אותו לפני שאתם מרפים כלל גשר, כי המודל שהוא מתאר הוא מה שכל בדיקה למעלה מניחה.
החליטו אם אותם עמיתים צריכים לחלוק מקטע בכלל
התיקון הזול ביותר הוא בדרך כלל להפסיק לחלוק את השכבה השנייה כאשר הדרישה היא רק נגישות IP. VPN מנותב נותן לכל לקוח כתובת משלו, מסיר את תחום השידור המשותף והופך תנועה בין עמיתים להחלטת מדיניות במקום ברירת מחדל. אז לפורטל יש כתובת אחת להגן עליה ואין שכנים שיכולים לתבוע אותה.
אם המקטע חייב להישאר, בדקו את ההגדרה בצד השרת שמאפשרת ללקוחות להגיע זה לזה: grep -n client-to-client /etc/openvpn/server.conf. כשהיא מושבתת, תנועת הלקוחות עוברת דרך השרת וניתן לסנן אותה שם. כשהיא מופעלת, עמיתים מחליפים מסגרות ישירות דרך הגשר, ונקודות הסינון שלכם הן הגשר וחומת האש של המארח.
רשמו על אילו הגנות כל מארח באמת נשען: אימות מנהרה, בידוד מקטע או TLS של היישום. מארח שנשען על כל השלושה בסדר. מארח שנשען על הראשון ומניח שהשניים האחרים באו איתו הוא זה שבסופו של דבר מגיש את התוכן הלא נכון.