מכשיר אחד דרך VPN של ראוטר דורש שלושה כללים, לא מתג

ב-VPN של ראוטר אין מתג לכל מכשיר; המתג שאתם מחפשים הוא קיצור דרך שכותב עבורכם כללי ניתוב לפי מדיניות. ברגע שמחשב נייד אחד, טווח פורטים אחד, רשימת כתובות אחת או מקטע LAN אחד צריך לעבור דרך המנהרה בעוד כל השאר נשאר ב-WAN, אתם בונים נתיב מדיניות ולא מפעילים תכונה. למשימה שלושה חלקים נעים, וכל אחד נכשל אחרת: טבלה מסומנת בלי נתיב נראית כמו שקט, סימון שהוחל בשרשרת הלא נכונה נראה כאילו לא קרה דבר, וכלל NAT חסר נראה כמו מנהרה שמתחברת ולא מעבירה דבר. שני חלקים נוספים נעלמים כי הם לא מופיעים לעולם בכלל ה-mangle, והם DNS ו-IPv6.

המיתוס: המנהרה היא הגדרה של לקוח

לקוח VPN בצד הראוטר עושה דבר אחד גס היטב: הוא שם 0.0.0.0/0 בטבלת הניתוב הראשית ומפנה אותו אל המנהרה. WireGuard גוזר זאת מ-AllowedIPs, OpenVPN מ-redirect-gateway שנדחף, ושניהם משנים את הנתיב לכל מארח מאחורי הראוטר. צמצום AllowedIPs או הוספת route-nopull משנה את מה שהלקוח מתקין. זה לא משנה למי ההתקנה חלה, כי הלקוח לא רואה מכשירים. הוא רואה רק מנות.

בחירה לפי מקור או יעד היא החלטת ניתוב, ולכן היא שייכת לשכבת המדיניות של הראוטר: כלל mangle ועוד טבלה שנייה ב-RouterOS, MARK ועוד ip rule ב-OpenWrt או DD-WRT, או כלל חומת אש שהשער שלו הוא המנהרה ב-pfSense. מתכון לקוח ה-WireGuard של Netgate הוא מה שכדאי לקרוא לפני ניחושים, כי בפלטפורמה הזו שער הכלל, הקצאת הממשק ורשומת ה-NAT היוצאת חייבים להתאים לפני שלקוח אחד משתמש במנהרה.

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

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

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

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

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

RouterOS 7 מפריד את מה ש-6.x החזיק יחד: אתם מצהירים על הטבלה עם /routing table add name=vpn fib, ואז מפנים אליה בשם בנתיב ובכלל ה-mangle. קטע 6.x שמכניס routing-mark בשורה בלי להגדיר את הטבלה נטען נקי ולא מתאים לשום דבר. המקרה הקלאסי האחר הוא שני חצאים של 0.0.0.0/1, או שתי ברירות מחדל באותו מרחק בטבלה אחת: הגרעין בוחר אחת, וההתנהגות עשויה להשתנות אחרי אתחול.

חלק שני: סימון לפני חיפוש הנתיב

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

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

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

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

השרשרת אינה בחירה של סגנון. עד שמנה מגיעה ל-FORWARD חיפוש הנתיב כבר קרה, ולכן MARK או DROP שם יכולים רק לשכתב או לזרוק. הסימון חייב ליפול ב-PREROUTING לתעבורה מועברת וב-OUTPUT לתעבורה שהראוטר עצמו יוצר, כי שם חיים ה-DNS, ה-NTP ובדיקות העדכון של הראוטר. נתיב היציאה הזה הוא הסיבה הרגילה לכך שהתקנה מנוהרת לגמרי עדיין עונה מהפותר של ה-ISP בבדיקת דליפה.

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

חלק שלישי: NAT, DNS וחריג ה-LAN

תעבורה שיוצאת דרך המנהרה צריכה כתובת מקור שהצד הרחוק יענה לה. הגבילו את התרגום לממשק המנהרה: out-interface=VPN_NAME ב-RouterOS, ‎-o tun0 בלינוקס, רשומת NAT יוצאת מתאימה ב-pfSense. כלל masquerade בלי הגבלה כזו משכתב תעבורה שרציתם להשאיר בשקט, והתסמין הוא שהמכשיר שאינו מנוהר מאבד את הכתובת הציבורית שלו.

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

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

כשהכלל מתאים אבל היישום עדיין משתמש ב-WAN

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

IPv6 הוא העקיפה השקטה. למכשיר יש משפחת כתובות שנייה עם נתיב ברירת מחדל משלה ומערכת כללים משלה, והתאמה של כתובת IPv4 בלבד היא חצי מדיניות. החילו את אותו בורר על ip6tables או על המקבילה ב-nftables, או השביתו IPv6 במקטע הזה בכוונה ולא במקרה.

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

אמתו עם שני מכשירים ואתחול

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

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

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