Dante SOCKS דרך VPN: מנהרה מלאה לעומת ניתוב לפי מקור

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

שני עיצובים, שני רדיוסי נזק שונים

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

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

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

מה עושה הגדרת external של Dante

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

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

ודאו שהכתובת המוגדרת באמת שייכת למנהרה בתוך מרחב השמות של הרשת של הפרוקסי.

בניית הטבלה לפי בחירת מקור

עבור כתובת TUN של 10.90.0.2/24 עם עמית נגיש ב-10.90.0.1, ומספר טבלה ששום דבר אחר לא משתמש בו, הסידור נראה כך:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

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

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

איפה כלל המקור דולף

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

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

IPv6 זקוק לכללים ולנתיבים משלו, כי סידור IPv4 לא מוכיח עליו דבר.

בחרו לפי הכשל שאתם יכולים לסבול

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

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

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