לנתב רק שירות ווב מקומי אחד מחוץ ל-VPN לפי פורט

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

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

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

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

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

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

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

בנו טבלת חזרה שלמה לפני שהכלל מצביע עליה

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

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

קראו את המספרים מהמארח החי במקום להעתיק אותם. ip -4 rule show אומר לכם אילו עדיפויות תפוסות, והוספת כלל בעדיפות שכבר קיימת משנה בשקט את הסדר של שני כללים שכל אחד מהם נראה תקין לבדו.

שני בוררים עושים כאן את העבודה האמיתית. iif lo הוא הדרך שבה הגרעין מדווח על מנות שהמארח יצר בעצמו, ולכן הכלל לא יכול לתפוס בטעות תעבורה מועברת שמגיעה מבחוץ. ipproto tcp sport 443 מצמצם אותו לתעבורה אחת ולפורט אחד, שזה צר ככל שהדרישה מאפשרת. הסירו את בורר הפרוטוקול והכלל יתפוס גם UDP 443, שהוא שירות אחר עם התנהגות אחרת.

השאירו תשובות פרטיות בתוך המנהרה

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

ip -4 route add table 100 throw 10.90.0.0/24

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

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

בדקו TCP, אחר כך QUIC, אחר כך אתחול

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

HTTP/3 מוגש מעל UDP ולא יותאם על ידי כלל TCP, ולכן מאזין QUIC צריך בורר משלו, אחרת ימשיך להשתמש במנהרה בזמן ש-HTTPS עובד. שמרו את הכללים שתבחרו ברכיב שמחזיק בממשק, ואמתו אותם אחרי התחברות מחדש או חידוש DHCP. כשמנהל מתחרה מסיר נתיב זמן ריצה אחרי אתחול, זו בעיית בעלות שצריך לתקן במקור, לא סיבה להוסיף כללי NAT רחבים יותר מעל.