מארח ציבורי אחד ל-VPN ולרשת: איך מחלקים את התפקידים

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

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

בחרו את בעל הכתובת לפני הפורטים

נקודת קצה של מנהרה ושרת אינטרנט יכולים לחלוק קרינל; חלוקה של כתובת, פורט ופרוטוקול אחד בו-זמנית היא מה שנכשל. WireGuard בדרך כלל תופס UDP 51820, OpenVPN תופס UDP 1194 או TCP 443, ושרת אינטרנט תופס TCP 443. הזוג שכואב הוא OpenVPN מעל TCP 443 לצד HTTPS, מפני ששניהם רוצים את אותו סוקט והקרינל נותן אותו למי שנקשר ראשון. רק דה-מולטיפלקסר מלפנים, כמו sslh או פרוקסי שמכיר TLS, מאפשר להם לחלוק את הפורט הזה, והוא מוסיף רכיב שכשל שלו נראה בדיוק כמו בעיית חומת אש.

הביטו בבעלים לפני שאתם משנים משהו: ss -lntup מדפיס את הכתובת המקומית, הפורט והתהליך של כל סוקט מאזין. שתי שורות שמראות 0.0.0.0:443 אומרות שהשירות השני מעולם לא נקשר, כמה שמח היה סקריפט ה-init שלו. גישור מזיז גם את הבעלים. כאשר eth0 מצטרף ל-br0, הכתובת IP עוברת ל-br0 וכל כלל חומת אש שמזכיר את eth0 מפסיק להתאים, אז קשרו שירותים על הגשר ואמתו עם ip -br addr.

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

נתבו בין שתי רשתות ה-LAN או עשו NAT לצד אחד

שתי רשתות LAN שלא רואות זו את זו יכולות כל אחת לחייג למארח הציבורי, שמעביר אחר כך בין המנהרות. העיצוב המנותב הזה צריך שלושה דברים: העברה דלוקה, נתיב לכל קידומת מרוחקת ומדיניות העברה שמאפשרת את המעבר. sysctl -w net.ipv4.ip_forward=1 מכסה את הראשון, ip route add 10.20.0.0/24 dev wg1 את השני, ושורת nftables כמו nft add rule inet filter forward iifname "wg0" oifname "wg1" accept את השלישי.

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

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

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

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

שלושה פקודות הופכות את הבדיקה למוחשית. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ מוכיח שהמאזין המקומי עונה בלי DNS חיצוני, wg show בלקוח מוכיח שלחיצת היד הושלמה, ו-tcpdump -ni any port 51820 ברכז מפריד בין בעיית ניתוב לבעיית מפתח. לחיצת יד שלעולם אינה מופיעה בלכידה מתה לפני המארח: חומת אש של הספק, כתובת ציבורית שגויה או כלל NAT בדרך.

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

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

קווי גישה של IPv6 בלבד ושירותי IPv4

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

בדקו כל משפחה בנפרד עם curl -4 ו-curl -6, כי בקשה מוצלחת אחת לא אומרת דבר על המסלול שלא ניסיתם. בעלות על פורט אינה משתנה בין משפחות, אבל המאזין כן: ss -lntup מפרט סוקטים של IPv4 ו-IPv6 בשורות נפרדות, ו-0.0.0.0:443 אינו מכסה [::]:443 אלא אם התהליך ביקש סוקט דו-מחשבתי.

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