למה שרת VPN מאחורי CGNAT לא מקבל חיבורים לעולם

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

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

הסימנים שמצביעים על NAT של הספק

השוו את כתובת ה-WAN בעמוד הסטטוס של הנתב לכתובת שמדווחת בדיקה חיצונית. כתובת WAN בתוך 100.64.0.0/10 היא הסימן הרגיל, והטווחים הפרטיים 10/8, 172.16/12 ו-192.168/16 אומרים אותו דבר. אם traceroute מציג את אותה קפיצה ציבורית שוב ושוב, או קפיצה מוקדמת עונה בכתובת פרטית, יש מתרגם נוסף בין הנתב לאינטרנט. חלק מספקי האינטרנט מציגים את הכתובת שהוקצתה רק בפורטל הלקוחות, לכן ייצאו את הערך הזה יחד עם ה-traceroute.

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

למה העברה ו-DNS דינמי לא יכולים לתקן את זה

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

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

העברה דרך VPS עם נתיבים מפורשים

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

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

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

השורה iroute אומרת ל-OpenVPN איזה לקוח מקבל את התעבורה של תת-הרשת הביתית; השורה route מכניסה את תת-הרשת הזו לטבלת הקרנל של ה-VPS כדי שחבילות ייכנסו למנהרה בכלל. לשירות מפורסם, הוסיפו כלל NAT יעד שמעביר את הפורט הציבורי אל 10.8.0.10 והפעילו את net.ipv4.ip_forward.

בדקו את המסלול מבחוץ

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

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

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

חלופות שכדאי לתמחר קודם

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

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