OpenVPN במנהרה מלאה: הוספת יציאת אינטרנט בצד השרת

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

דחפו את נתיב ברירת המחדל ואמתו מה הלקוח התקין

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

push "redirect-gateway def1"

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

העברה היא הגדרת שרת, לא הגדרת VPN

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

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

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

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

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

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

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

תנו לתשובות מקום ללכת אליו

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

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

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

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

הוכיחו את זה מהלקוח, לא מהמעטפת של השרת

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

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

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