סמל ירוק, אותה IP ציבורית: איזה מסלול ה-VPN דילג עליו

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

מה הלקוח באמת התקין

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

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

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

שלוש צורות של ניתוב סלקטיבי

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

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

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

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

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

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

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

פתרון שמות הולך בדרך משלו

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

resolvectl status | head -20
resolvectl query example.org

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

ארבע תצפיות שמכריעות את העניין

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

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

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